Core Web Vitals in plain language

Somewhere in a report, you've met LCP, INP and CLS. Three abbreviations Google calls the Core Web Vitals, presented as if everyone were born knowing what they mean.

Before the definitions, one thing frames the rest. Each of them measures something a visitor feels, not something only an engineer cares about. That's why they deserve your attention, and why Google uses them as a ranking signal in search.

LCP (how long until the page is actually there?)

Largest Contentful Paint measures the time from when a visitor requests your page until the biggest piece of content, usually the hero image or main headline, is on screen.

It's the metric closest to what a normal person means by is this site fast? Not when the first pixel appears or when the spinner shows up, but when the thing they came for is visible.

The usual suspects are oversized images, slow server responses, and stylesheets or scripts that block the page from rendering.

INP (when I tap something, does anything happen?)

Interaction to Next Paint measures how long the page takes to visibly respond when a visitor clicks, taps or presses a key. Not to finish the task, just to show that something happened.

This is the metric behind the most quietly infuriating experience on the web, tapping a button and wondering whether it registered. (INP replaced an older metric called FID in 2024; if you see FID in an old report, INP is its stricter successor.)

The usual suspect is JavaScript, too much of it doing too much work at exactly the moment the visitor wants the page's attention.

One wrinkle is that INP needs a real human interacting, so lab tests can't measure it directly. Lab tools (including Lighthouse) use Total Blocking Time (TBT) as a stand-in. It measures how long scripts hog the page and would have made it unresponsive if someone had tapped.

CLS (does the page jump around?)

Cumulative Layout Shift measures how much the page's content moves after it has appeared. You know this one personally. You go to tap a link, an ad loads above it, everything lurches, and you've tapped something else entirely.

The usual suspects are images and embeds without reserved space, late-loading banners, and web fonts that swap in at a different size.

The fine print that changes how you read Core Web Vitals

Two details turn these from trivia into something you can act on.

They're judged at the 75th percentile. Google doesn't ask how the page performed on average. It asks whether at least 75% of real visits were good. One fast visit proves nothing; your slowest quarter of visitors is what's being graded. That's also why we report distributions (p50, p75, p90, p95) rather than a single number in Webperf Audit.

Field data and lab data answer different questions. The official Core Web Vitals verdict comes from field data, gathered from real Chrome users via the CrUX dataset, and it trails reality by weeks because it's collected over a rolling 28-day window. Lab data (Lighthouse) is measured under controlled conditions, so it's ideal for comparing pages and re-testing a fix today. You want both, and you want to know which one you're looking at. (We've written more on this in Webperf Cloud vs PageSpeed Insights.)

What to actually do with them

  1. Find out which metric is your problem. There's no point optimising JavaScript if your issue is a 4 MB hero image. A whole-site audit tells you which vital fails, on which pages, and why.
  2. Fix by template, not by page. The pages dragging your p75 down usually share a template, so one fix improves hundreds of pages.
  3. Re-test in the lab immediately, confirm in the field later. Lab scores tell you the same day whether the fix worked mechanically; CrUX confirms over the following weeks that real visitors feel it.

Three abbreviations, and each maps to a feeling. The page is there, it responds, and it holds still.

Webperf Audit reports LCP, INP and CLS as distributions, page by page. See which plans include it, or email hello@webperf.cloud.