Core Web Vitals: what actually moves LCP, INP and CLS

Core Web Vitals are assessed on what real visitors experienced, aggregated at the 75th percentile over twenty-eight days, and reported through the Chrome User Experience Report. Search Console's Core Web Vitals report is the same data grouped by URL pattern, which makes it the right starting point for any performance work. Lab tools like Lighthouse simulate one load, from one location, on one throttled profile — invaluable for diagnosis, useless as a verdict.

The gap between the two routinely surprises teams. A page scoring 95 in the lab can sit in the poor bucket in the field, because real visitors are on mid-range phones, on mobile networks, with a cookie banner, three tag manager containers and a chat widget the developer disabled locally months ago. When lab and field disagree, the field is what your customers lived and what Google uses.

Work by template rather than by URL. The field report groups similar pages precisely because a single URL rarely has enough traffic for a reliable percentile. Fixing the product template moves thousands of pages; optimising one homepage moves one, and it is almost never the homepage that is failing.

Largest Contentful Paint measures when the main content becomes visible; under 2.5 seconds is good. It decomposes into four parts, and knowing which one dominates saves weeks: time to first byte, resource load delay, resource load time, and render delay. A page with a slow server has a TTFB problem that no image optimisation will fix; a page with a fast server and a 4-second LCP is usually blocked by CSS, fonts or a hero image nobody prioritised.

The fixes that repay effort most reliably: serve the LCP image in a modern format at the size it is actually displayed, preload it, remove render-blocking scripts from the head, and make sure fonts do not hold text hostage. On server-rendered sites, caching at the edge frequently halves TTFB for a fraction of the cost of any front-end work.

The single most common structural mistake is lazy-loading the LCP element. A hero image marked `loading="lazy"` is deferred past layout by the browser, which is exactly the opposite of what you want — lazy-loading belongs below the fold, never above it.

Interaction to Next Paint replaced First Input Delay in March 2024, and it is a far harsher measurement: where its predecessor looked only at the first interaction, INP considers the worst interaction of the whole visit. Under 200 milliseconds is good. It is almost always a JavaScript problem — long tasks blocking the main thread, oversized event handlers, hydration of components nobody scrolled to.

What makes INP organisationally difficult is that the offending scripts frequently do not belong to engineering. Consent management platforms, tag managers, analytics, session recording, chat widgets and A/B testing tools all compete for the same main thread, and each one was added by someone who was not thinking about interaction latency. An INP audit is often, in practice, a tag audit.

The technical fixes are well established: break long tasks into smaller chunks so the browser can respond between them, defer anything not needed for the first interaction, and load third-party scripts after interactivity rather than before. On many sites the single biggest INP win is removing tags nobody has looked at in two years — free, immediate, and requiring only that someone is willing to ask who owns each one.

Cumulative Layout Shift measures how much visible content moves unexpectedly; under 0.1 is good. The causes are a short and well-known list: images and iframes without width and height attributes, ads and embeds injected above existing content, web fonts swapping at different metrics, and cookie banners that push the page down after the first paint.

Every cause has the same fix: reserve the space before the content arrives. Set explicit dimensions or aspect ratios, give ad slots a fixed container, use font loading strategies that do not reflow the page, and render consent banners as an overlay rather than as a block that displaces content. None of this is hard; it is simply invisible on the fast connection where developers work, because everything loads before the first frame.

CLS is worth fixing even where it is not failing, because it is the metric users feel most directly. A layout shift that moves a button under a finger is not a score, it is an order placed on the wrong product and a support ticket. Test on a throttled mobile profile and on the templates with the most traffic, not on the homepage.

As a ranking signal, page experience is real and modest. Google has been consistent that it breaks ties between results of comparable relevance rather than promoting a fast page over a more useful slow one. Anyone selling a performance sprint as a ranking strategy is overselling; anyone ignoring a site rated poor across its main templates is leaving something on the table.

The business case is conversion, and there the evidence is much stronger. Public studies — Deloitte's retail work, Vodafone's LCP experiment, the case studies collected on web.dev — repeatedly land in the same range: roughly 0.4 to 1.0 per cent of relative conversion movement per 100 milliseconds of LCP, strongest on mobile, on long journeys and on transactional intent. Our Core Web Vitals ROI simulator lets you set that elasticity yourself rather than hiding it in a constant.

Two planning rules follow. Returns are not linear: moving a template from 5 seconds to 3 changes behaviour visibly, moving from 2.2 to 1.9 rarely does and often costs more engineering. And verification belongs in the field, twenty-eight days after the deploy — not in a lab score taken on release day, which measures the developer's laptop rather than the customer's phone.