Right after deploying the first slice of internationalization work to production, a Lighthouse run came back with Performance: 89 — below the project's own ≥90 hard-rule threshold, and a real drop from the 93/100/99 baseline measured the same day, before that deploy.
The obvious move is to assume the new code regressed something and start reverting. I didn't, and the reason why is the more useful part of this story.
Reading the report instead of reacting to the number
A single Lighthouse score is one HTTP request's worth of data, from one serverless cold start, at one moment. Before treating 89 as a verdict, I opened the actual report and looked at what was driving the score down rather than the headline number alone.
The server-response-time audit showed a 1,150ms root-document TTFB —
roughly 15-20x the value from every prior run of this same page. That single
number cascaded into speed-index scoring 12.7s (score 0.03), because
nothing on the page can paint until the document itself arrives.
Note
1,150ms of pure time-to-first-byte, with every other metric explained by that one number, doesn't look like a rendering regression from new code. It looks like the server took unusually long to respond to this one request — which on a serverless platform, is what a cold start looks like.
Testing the hypothesis instead of assuming it
A hypothesis isn't a conclusion. I re-ran Lighthouse against production twice more, a few minutes apart:
- Run 2: 94/100/100/100 —
server-response-timeback to ~70ms, matching the pre-deploy baseline almost exactly.speed-indexback to 1.4s (score 1). - Run 3: consistent with run 2.
The 72KB core JS chunk that Lighthouse's bootup-time/mainthread-work-breakdown
audits flag on every run of this site — a pre-existing, already-tracked
piece of technical debt, unrelated to this deploy — was byte-for-byte
identical across the 89-scoring report and the 94-scoring one. If the new
code had actually regressed something, that chunk (or a new one) would look
different between the two runs. It didn't.
Decision
No revert. The evidence pointed at a one-off cold-start spike on a serverless platform, not a durable regression from the deploy — and the repeat measurements confirmed it rather than just asserting it. Reverting on a single data point would have thrown away real, shipped work to "fix" a problem that the second and third runs showed didn't exist.
What I'd do differently
Nothing about the investigation itself — reading the underlying audits instead of the headline number, then re-measuring instead of assuming, is exactly what caught this correctly. If anything, I'd build repeat-measurement into the standard post-deploy check from the start, rather than only reaching for it after a scary first number.