Core Web Vitals in 2026: What Actually Moves LCP, INP and CLS

Three metrics, three different causes, three different fixes — plus why lab data and field data disagree and which one Google actually uses.

Core Web Vitals get discussed as though they were three numbers to be gamed. They are better understood as three specific complaints a visitor might have about a page: it took too long to show me anything useful, it did not respond when I touched it, and it moved while I was reading. Each metric measures one of those complaints, and each has a different cause and a different fix.

The three metrics and what they actually measure

Largest Contentful Paint measures how long it takes for the biggest element in the viewport — usually a hero image, a video poster or a block of heading text — to finish rendering. The threshold for "good" is 2.5 seconds. It is a proxy for the moment a page stops looking empty.

Interaction to Next Paint replaced First Input Delay in March 2024, and the change matters. FID measured only the delay before the browser began processing your first interaction, which flattered pages that responded quickly and then did nothing useful. INP measures the full duration from interaction to the next visual update, across the whole page visit, and reports close to the worst one. The threshold is 200 milliseconds. It is much harder to score well on, and much more honest.

Cumulative Layout Shift measures how much content moves around after it has been painted, scored by how much of the viewport moved and how far. The threshold is 0.1. It is the metric behind the experience of reaching for a link and having an advert push it out from under your finger.

All three are assessed at the 75th percentile of real visits, which is the detail most people miss. Your fast laptop on office wifi is not the measurement. Three quarters of your actual visitors have to hit the threshold, and that population includes mid-range Android phones on mobile networks.

Lab data and field data disagree for a reason

Running Lighthouse gives you lab data: a single simulated load, on a modelled device, under throttled network conditions. It is reproducible and it is useful for diagnosis, because it tells you what a page does.

Field data — the Chrome User Experience Report, and the "Core Web Vitals" section in Search Console — is what Google actually uses. It is collected from real Chrome users over a rolling 28-day window. Those two sources routinely disagree, and when they do, the field data is right and the lab data is a model.

The 28-day window has a practical consequence worth planning around: fix something today and the field metric will not fully reflect it for about a month. Teams regularly ship a genuine improvement, check Search Console three days later, see nothing, and conclude it did not work. Lighthouse is the right tool for confirming a fix landed; Search Console is the right tool for confirming it mattered.

What actually moves LCP

LCP problems are usually not slow images. They are usually late-starting images.

The sequence that causes most bad LCP scores is: the browser downloads the HTML, discovers a stylesheet, blocks on it, builds the layout, discovers the hero image is needed, and only then starts fetching it. The image itself may download quickly. It just started two seconds too late.

The fixes follow from that. Preload the hero image so the browser starts fetching it immediately rather than after the CSS resolves. Do not lazy-load anything above the fold — applying lazy loading to the hero is a spectacularly common own goal, because it guarantees the most important image is requested last. Serve it at an appropriate size in a modern format. And keep the critical CSS small, because the stylesheet is the thing blocking discovery in the first place.

Server response time sets the floor under all of this. If the HTML takes 800 milliseconds to arrive, you are spending a third of the budget before the browser has seen anything at all.

What actually moves INP

INP is a main-thread problem. JavaScript runs on the same single thread that handles rendering and input, so while a script is executing, nothing else can happen — including responding to a tap.

The usual causes are long tasks: a large bundle parsing and executing during hydration, an event handler doing heavy work synchronously, or a third-party script running whenever it feels like it. The measurement covers the whole visit, so a page that loads fast and then locks up when someone opens a menu scores badly, correctly.

The most effective fixes are about doing less rather than doing it faster. Ship less JavaScript. Break long tasks into smaller pieces so the browser can respond between them. Move genuinely heavy computation off the main thread. And audit third-party scripts honestly — analytics, chat widgets, ad tags and tag managers frequently account for more main-thread time than the site's own code, and each one was added by someone who assumed it was free.

Unminified JavaScript deserves a specific mention, because it is invisible in a way file size is not. Minification does not only reduce bytes; it reduces the work the browser does parsing and compiling. Shipping unminified bundles to production can easily double the parse cost, and on a mid-range phone that is real interaction delay rather than a rounding error.

What actually moves CLS

CLS has the simplest causes and the simplest fixes, which is why a bad CLS score is usually a sign nobody has looked.

Images and videos without dimensions reserve no space, so the page reflows when they arrive. Set width and height, or use an aspect-ratio box. Ad slots and embeds do the same thing, more violently, because they tend to sit in the middle of content — reserve their space in advance, and accept a blank area rather than a jump.

Web fonts cause a subtler version. When a fallback font is swapped for the real one, text reflows if the two have different metrics. Using font-display: swap keeps text visible during loading, and choosing a fallback with similar metrics limits how far things move when the swap happens.

The one that catches people out is content injected at the top of the page after load — a cookie banner, a promotional bar, a notification. Anything inserted above existing content pushes all of it down, and that is a large shift by definition. Overlay it, or reserve its space.

How much of this affects rankings

Honestly: less than the amount of discussion suggests. Core Web Vitals are part of the page experience signals, and Google has been consistent that relevance and content quality dominate. A fast page about nothing will not outrank a slow page that answers the question.

What they reliably affect is everything downstream of the visit. Slow pages lose visitors before the content loads, and a page nobody waits for cannot convert, rank on engagement, or earn a link. The argument for fixing Core Web Vitals is not that Google will reward you. It is that the 75th percentile of your visitors is having a worse time than you think, and the metrics are simply telling you so.