Core Web Vitals, explained without the jargon

For years, "site speed" meant a single number that different tools disagreed about, measured in ways that had little to do with what a visitor actually experienced. A page could score well and still feel slow, or score poorly and load perfectly well for a real person clicking around it. Core Web Vitals is Google's attempt to fix that: three specific, published measurements, each aimed at one thing a visitor actually notices, with a public threshold for what counts as good.

They matter for two reasons. First, they are a reasonable proxy for how a page actually feels to use, which is worth caring about regardless of search engines. Second, Google uses them as one input among many into search ranking, which is covered separately in does site speed affect search rankings. This article is about what the three metrics actually measure.

The three metrics, and what each one is really asking

These are Google's own published thresholds, and each metric is scored on the same three-band scale: good, needs improvement, and poor, with poor starting well above the good threshold rather than immediately after it.

Largest Contentful Paint — does it look loaded?

LCP identifies the largest element in the visible part of the page — usually a hero image, a large heading, or a block of text — and measures the time from navigation until that element has fully rendered. It is a stand-in for the question a visitor is actually asking: has anything I care about shown up yet?

LCP is dragged down by a slow server response before anything can start rendering, by a large image or video that has not been sized or compressed for the space it occupies, and by fonts or scripts that block rendering while they load. It is one of the metrics most directly affected by server response time, which is why improving LCP often starts with what happens before the browser even receives the page.

Cumulative Layout Shift — does it hold still?

CLS is different in kind from the other two: it is not measuring time at all. It measures how much visible content moves without the visitor doing anything — an image that pops in and pushes the text below it downward, a banner that loads in above the paragraph you were about to tap, a web font swap that reflows a whole block of text at a different size.

Each shift is scored by how much of the screen moved and how far, and the scores for the whole page load are added together. A page can be perfectly fast by every other measure and still score badly here if things keep rearranging themselves while a visitor is trying to read or tap. Fixing layout shift is mostly about reserving space in advance for anything that loads in later — images, embeds, ads, fonts — rather than anything to do with server speed at all.

Interaction to Next Paint — does it respond?

INP measures the delay between a visitor interacting with the page — a click, a tap, a key press — and the browser actually updating the screen in response. It replaced an older, narrower metric called First Input Delay in March 2024, because measuring only the very first interaction missed a page that loaded quickly and then became sluggish once a visitor started actually using it.

INP is almost entirely a JavaScript problem. A page with a lot of script running on the main thread — trackers, chat widgets, animation libraries, a bloated theme — can leave the browser too busy to respond immediately to input, even though the page finished loading some time ago. There is very little a server can do about this: the fix lives in how much JavaScript the page runs and how it is structured, not in hosting.

What Core Web Vitals do not measure

They are not a complete picture of speed, and they were never meant to be. A site can pass all three comfortably and still be slow to use in ways these metrics do not capture — a search feature that takes a long time to return results after the initial page has loaded, for instance, or a checkout flow with a slow step three pages in. Core Web Vitals are about the initial load and the first interactions; they say nothing about everything that happens afterwards.

They also do not distinguish cause from effect. A poor LCP score tells you the largest element was slow to render — it does not tell you whether that is because of an unoptimised image, a slow server, or a font blocking the page. Reading the score is the start of the diagnosis, not the end of it: a waterfall chart is where you go to find the actual cause behind the number.

Where hosting fits in, and where it does not

Server response time is a genuine input into LCP — a slow server delays everything downstream of it, including the largest element rendering. That is the one place in Core Web Vitals where hosting has a direct, measurable effect, and it is covered in does hosting actually affect site speed.

CLS and INP, on the other hand, are decided almost entirely by how a page is built: whether images and embeds reserve their space in advance, and how much JavaScript runs and how it is written. No amount of server capacity fixes a page that reflows as it loads or a script that blocks the main thread — those are decisions made in the page itself, and they are the same on the fastest server available as they are on the slowest.

Start by testing your own pages against these thresholds using a proper speed test, then work through whichever of the three is furthest from good.