Three Core Web Vitals myths we ignored last year
A practical note from the engineering team on what does and does not move the metrics that matter.
We had a stretch last year where almost every new client engagement included a Core Web Vitals audit at the start. They are useful. They are also surrounded by a lot of received wisdom that does not survive contact with a real codebase.
The first myth is that the metric to optimise for is Lighthouse score. It is not. Lighthouse runs a single synthetic test from a single Chromium instance and reports a number on a curve that has been adjusted three times in the last year. The metric to optimise for is field data — actual page-load measurements from actual users on actual networks. Search Console gives you that for free.
The second myth is that a heavy JavaScript framework is automatically bad for Core Web Vitals. It can be, but the framework itself is rarely the problem. The problem is almost always how the framework was used — too much hydration, server components rendered in the wrong order, third-party scripts loaded eagerly when they should have been loaded on interaction. We have measured a heavily customised Next.js site at sub-200ms LCP and a hand-written static site at 2.1 seconds. The toolchain is a tool, not a guarantee.
The third myth is that fixing performance is a one-time engagement. It is not. Performance is an emergent property of every change shipped to a codebase, and without budgets in CI it regresses inside a quarter. We now write performance budgets into the deploy pipeline of every project we ship. They are unfashionable and they are also the reason the sites we built three years ago still pass today.