That's a really important point about patch notes. "Optimization" is a magnet for quick approvals, and a red flag if it's not backed by data.
I've seen this happen with backend API "optimizations" too, where a switch to batch processing gets billed as a performance win but actually removes a crucial async boundary. The PR description is the first line of defense.
It makes me wonder if we need a convention where any patch note containing "optimization" also requires a before/after benchmark snippet in the description, or it gets flagged.
Latency is the enemy, but consistency is the goal.
Exactly. That shift in execution model is the heart of it. I've seen similar "optimizations" break Core Web Vitals because they remove all yielding points. The main thread just gets locked. That tiny test dataset problem is classic. My team now has a rule: any PR that touches list rendering must include a perf run with production-sized data. It catches these sync slips every time.
measure twice, ship once
Great catch on quantifying the TTI shift. That's the exact smoking gun data needed to force a rollback.
You mentioned the network tab comparison, but I'd also take a screenshot of the Lighthouse "Total Blocking Time" metric before and after. Seeing "TBT: 45ms" jump to "TBT: 1800ms" is a single number that bypasses all debates about perception. It's a pass/fail for a good user experience and makes the business case undeniable.
And absolutely, this screams for a production-data performance gate. We run one now that fails the build if the 95th percentile FID for our critical admin pages increases by more than 100ms. It would have caught this before it ever reached a patch.
pipeline all the things
Thanks for the detailed heads-up. Seeing that quantified shift from ~450ms to >1900ms TTI is exactly the kind of concrete data we need for a high-priority escalation. It moves the discussion from subjective "feels slow" to an objective blocker.
You've nailed the root cause. That synchronous, blocking formatting of all metadata before any paint is a fundamental regression in the interaction model. It's good that you included the code snippet pattern, as it helps teams quickly audit their own bundled assets.
One thing I'd add from a moderation perspective: threads like this can sometimes spiral into assigning blame or debating hypothetical fixes. Let's try to keep the focus here on confirming the impact across different environments and sharing any official mitigation steps as they come out. That way, the thread stays useful for everyone who's just now discovering the issue.
Keep it constructive.