BUILD
Core Web Vitals: what actually moves them
5 min read
Core Web Vitals assessments use field data from real visitors, not the lab score a testing tool produces, so optimisation should target the conditions real users experience rather than the number that is easiest to improve.
Core Web Vitals generate a lot of activity and not much improvement, mostly because teams optimise the number a tool shows them rather than the number being assessed.
The distinction is the first thing worth understanding, and after that the list of things that genuinely move the metrics is shorter than most audits suggest.
Lab data and field data are different numbers
A performance testing tool runs a single simulated load on a defined connection and produces a lab score. The assessment Google uses comes from field data: measurements collected from real visitors on their own devices and networks, aggregated over a rolling window.
They disagree frequently, and when they do the field data is the one that counts. A site can score well in the lab and fail its assessment because real visitors are on slower devices than the simulation assumed.
This also means changes take weeks to show up, because the window has to refill. Deploying a fix and re-testing the next day tells you about the lab number only.
LCP: it is almost always one image or the server
Largest Contentful Paint measures when the main element becomes visible. In practice that element is a hero image or a block of text in a heading, and failures come from a small set of causes.
- A hero image that is far larger than its displayed size, or in an outdated format
- The main image loaded lazily, or discovered late because it is set in CSS rather than markup
- Web fonts blocking text rendering, with no fallback displayed meanwhile
- Slow server response, which delays everything after it regardless of front-end work
INP: too much JavaScript on the main thread
Interaction to Next Paint measures how quickly the page responds when someone interacts with it. Failures mean the main thread is busy when the user taps.
The usual causes are third-party scripts — tag managers, chat widgets, analytics, consent tools — and large client-side bundles doing work that could have happened on the server. Auditing what third parties are loaded, and removing the ones nobody can name an owner for, is often the single largest improvement available.
CLS: reserve the space
Cumulative Layout Shift is the most fixable of the three and usually comes from content that arrives after the first paint without a space reserved for it: images without dimensions, ads and embeds, banners injected at the top, and fonts that swap at a different size.
Setting explicit width and height on images, reserving space for anything injected, and matching fallback font metrics to the web font resolves the large majority of it.
What to do, in order
Read the field data first and find which metric is actually failing, and on which template and device type. Mobile and desktop usually differ enough that one of them is the whole problem.
Then fix the specific cause rather than working through a generic audit list. Most sites that fail have one dominant issue — an oversized hero, a heavy third-party script, an unreserved banner — and fixing it moves the metric more than a dozen marginal optimisations.
Then wait. The field data window takes weeks to reflect the change, and redeploying impatiently makes it impossible to attribute the improvement.
Questions we get asked
How much do Core Web Vitals affect search rankings?
They are a ranking signal and a modest one next to relevance and content quality. The stronger argument for fixing them is conversion: slow and unstable pages lose people before they act, and that effect is measurable on your own analytics rather than inferred.
What if our site has no field data?
That means too few visitors for the data set to report, and the assessment falls back to broader groupings. Lab testing is the only guide available in that case; it is worth remembering it models one device and connection rather than your actual audience.
How long after a fix do the numbers change?
Typically several weeks, because the assessment uses a rolling window of real visits that has to refill with post-fix data. Checking the next morning only shows the lab score, which is why fixes often get mistakenly judged ineffective.