Core Web Vitals: what actually moves the numbers

<strong>LCP</strong> measures when the largest visible element finishes rendering — usually a hero image, a heading, or a video poster. It answers whether the page felt like it loaded. Good is 2.5 seconds or less; above 4 seconds is poor.

<strong>INP</strong> measures responsiveness across the whole visit: for every interaction, the time from input to the next frame being painted, reported at roughly the worst case. It replaced First Input Delay in March 2024, and it is a considerably harder test, because FID only measured the delay before processing started while INP includes the work itself and the rendering that follows. Good is 200 milliseconds or less.

<strong>CLS</strong> measures unexpected layout movement during the visit — the content jumping as an image or ad loads and pushes text down. Good is 0.1 or less.

All three are assessed on real users at the 75th percentile over a 28-day window. That last detail matters: you are being judged by your slower quarter of visits, not your median, and certainly not by your developer laptop.

Lighthouse runs a simulated load on one device under synthetic throttling. It is a useful diagnostic and a poor predictor. Search results use field data from real Chrome users, collected in the Chrome User Experience Report.

The gap is usually explained by devices and networks. Your team tests on fast hardware over office fibre. A meaningful share of real visitors are on mid-range Android phones over congested mobile networks, where JavaScript execution can take several times longer.

INP is where lab testing is least informative, because a synthetic run cannot know which elements people actually click, or how heavy the page has become after ten minutes of use. Check PageSpeed Insights for field data, or the Core Web Vitals report in Search Console, before concluding anything.

Identify the LCP element first — the browser reports it, so there is no need to guess. On marketing pages it is nearly always the hero image or headline.

If it is an image, four changes account for most of the improvement: serve modern formats (AVIF or WebP), provide a responsive srcset so phones do not download desktop-sized files, set fetchpriority="high" on that one image, and never lazy-load it. Lazy-loading the hero is a common own goal that directly delays LCP.

If it is text, the usual culprit is font loading. Use font-display: swap so text paints immediately in a fallback, preload the one weight used above the fold, and self-host or use a provider that avoids an extra connection. Render-blocking CSS and synchronous scripts in the head are the other frequent cause — inline what the first screen needs and defer the rest.

INP problems are almost always too much JavaScript running on the main thread. Two patterns dominate: large bundles that must be parsed before anything responds, and long tasks that block the thread while the user is trying to interact.

Route-level code splitting is the highest-leverage fix — ship only what the current page needs rather than the whole application. Then find long tasks in a performance profile and break them up, yielding to the main thread so the browser can paint between chunks.

Third-party scripts deserve particular suspicion. Tag managers, chat widgets, session recorders, and A/B testing tools frequently contribute more main-thread work than the entire application. Audit what is loaded, remove what nobody reads, and defer the rest until after interaction. We have seen INP halve from removing two abandoned marketing tags.

CLS is the most mechanically fixable of the three. Reserve space for anything whose size is not known at parse time.

Set explicit width and height attributes on every image and video so the browser reserves the box before the file arrives. Give ad slots and embeds fixed minimum dimensions. Use CSS aspect-ratio for responsive media.

The subtler cause is fonts. When a fallback font is replaced by a webfont with different metrics, text reflows and shifts everything below it. size-adjust and the font-metric override descriptors let you match the fallback closely enough that the swap is invisible.

Finally, never insert content above existing content after load — cookie banners, promotional bars, and late-loading notices that push the page down are a reliable way to fail this metric.

Honestly: less than performance vendors imply, and more than sceptics claim. Core Web Vitals are a genuine ranking signal, but a modest one next to relevance and content quality. A fast page about the wrong topic will not outrank a slow page that answers the question.

Where the effect is unambiguous is conversion. Faster pages convert better, and that relationship is far stronger and better evidenced than the ranking effect. We treat search as the secondary benefit and revenue as the primary one.

The practical case for fixing Core Web Vitals is that it is one of the few technical projects where the work is well-defined, the metrics are public, and the outcome is measurable within weeks.