Core Web Vitals: what to fix first and what to ignore

Core Web Vitals are three field metrics Google collects from real Chrome users. They are a genuine ranking signal and a small one - they break ties between pages of comparable relevance and never overcome a content or link deficit.

Fix them because slow pages lose visitors. Treat the ranking effect as a bonus.

The three metrics

LCP - Largest Contentful Paint

When the biggest element in the viewport finishes rendering. Good: under 2.5 seconds.

Almost always one of four causes:

• A large hero image not preloaded, or served uncompressed at desktop size to phones.
• A render-blocking font. A webfont with font-display: block hides text until it loads.
• Slow server response. If TTFB is over 800ms, no front-end work will save you.
• Client-side rendering. If the content only appears after a JavaScript bundle parses and fetches data, LCP is whenever that finishes.

Fixes in order of effect: <link rel="preload"> the hero image, serve it as WebP at the size actually displayed, set font-display: swap, and render content on the server.

INP - Interaction to Next Paint

Replaced FID in 2024. Measures the delay from an interaction to the next visual update, across the whole page lifetime rather than just the first interaction. Good: under 200ms.

Almost always long tasks blocking the main thread:

• Third-party scripts. Analytics, chat widgets, tag managers, A/B testing. This is the number one cause and the easiest win.
• Large hydration. Frameworks hydrating the entire page at once.
• Expensive handlers doing layout work synchronously on every input.

Fixes: audit third-party scripts and remove what you cannot justify, defer the rest, break long tasks up, and hydrate only what needs interactivity.

CLS - Cumulative Layout Shift

How much visible content moves unexpectedly. Good: under 0.1.

Causes are short and always the same:

• Images without width and height, so the browser cannot reserve space.
• Ads, embeds and iframes with no reserved container.
• Webfonts swapping to a different metric.
• Content injected above existing content - banners, notices, consent bars.

CLS is the cheapest of the three to fix. Set explicit dimensions on every image and reserve space for anything injected.

Field data versus lab data

This distinction causes most confusion.

Field data is what real Chrome users experienced, aggregated over 28 days. This is what Google uses for ranking. It needs enough traffic to report at all, so a new site often has no field data.

Lab data is a simulated load from one location on throttled hardware. Useful for debugging because it is repeatable and immediate; not what you are ranked on.

Two consequences: a perfect lab score with poor field data means real users are on slower devices or networks than your test - trust the field data. And a fix takes up to 28 days to fully appear in field data, so do not judge it after a day.

What to actually do

If TTFB is over 800ms, stop and fix that first. Every other metric inherits it, and no amount of image optimisation compensates for a slow server.

Then, in order:

1. Set width and height on every image. Ten minutes, largest CLS win.
2. Preload the LCP image and serve it in a modern format at the right size.
3. Audit third-party scripts. Remove or defer everything you cannot justify by name.
4. font-display: swap on every webfont.
5. Reserve space for anything that appears after load.

What to ignore: perfect Lighthouse scores. 100 on a synthetic test proves nothing about field data, and chasing the last ten points costs days that would return more spent on content or links.