Core Web Vitals, explained properly

Core Web Vitals are Google's attempt to measure page experience with numbers rather than adjectives. There are three, they each capture a different kind of frustration, and each has a published threshold. Unlike most SEO metrics they are measured on real visitors using real devices, which is why a site can look fast on a developer's machine and fail in the field.

Largest Contentful Paint, and why it usually fails

LCP marks the moment the largest visible element finishes rendering, which is usually a hero image, a video poster, or a large block of heading text. It is the closest single number to the question a visitor is actually asking, which is whether anything has appeared yet. In practice, failures cluster around a handful of causes: an enormous unoptimised hero image, a slow server response before anything can start, render-blocking CSS or JavaScript in the head, a web font that hides text while it loads, and images served at far larger dimensions than they display at. The single most effective fix on most sites is compressing and correctly sizing the hero image, which is unglamorous and routinely worth more than a fortnight of other optimisation.

Interaction to Next Paint, the JavaScript tax

INP measures how long it takes for the page to visibly respond after someone taps or clicks. High values almost always mean the browser's main thread is busy running JavaScript when the visitor tries to interact. The usual culprits are heavy third-party scripts such as tag managers, chat widgets, and tracking pixels, oversized JavaScript bundles that must be parsed before anything responds, and event handlers doing too much work at once. This is where sites built by stacking plugins and marketing tags suffer most, because each addition is individually reasonable and collectively fatal.

Cumulative Layout Shift, the one users hate most

CLS quantifies the experience of reaching for a button and having the page move it. Every cause is preventable. Images and video without explicit width and height attributes leave the browser no way to reserve space. Ads and embeds injected into the flow push everything down. Web fonts swapping in at a different size shift the text beneath them. Content inserted above existing content, such as a cookie notice or a promotional banner, moves everything the visitor was already reading. Fixing CLS is mostly a matter of reserving space in advance for anything that arrives late.

Field data and lab data are not the same thing

This distinction matters and causes constant confusion. Lab data comes from tools such as Lighthouse running a simulated load on a simulated device, and it is useful for diagnosis because it is repeatable. Field data comes from the Chrome User Experience Report, which aggregates measurements from real Chrome users on their real devices and connections, and it is what actually counts for Search. A page can score well in Lighthouse and fail in the field, usually because real visitors are on slower phones and worse connections than the simulation assumes. Diagnose in the lab, judge by the field.

How much do they matter for rankings

Less than performance vendors imply and more than sceptics claim. Google has described page experience signals as one input among many, and relevance still dominates: a slow page that answers the question will outrank a fast page that does not. The stronger argument for fixing them is commercial rather than algorithmic. Speed affects whether people stay, whether they convert, and increasingly whether AI systems that fetch pages live manage to read yours before timing out. Treat Core Web Vitals as a proxy for whether the site respects the visitor's time, and the ranking question resolves itself.

Where to measure yours

1. 01Google Search Console has a Core Web Vitals report using field data, grouped by page type. This is the authoritative view for your own site.
2. 02PageSpeed Insights shows both field and lab data for any URL, including competitors, which makes it useful for benchmarking.
3. 03Chrome DevTools Lighthouse runs locally and is best for diagnosing a specific problem after a change.
4. 04The Chrome User Experience Report is the underlying public dataset if you want to analyse at scale.