Core Web Vitals
Date: 2026-08-16
Three field metrics standing in for loading, responsiveness and visual stability. They matter less because Google ranks on them and more because they’re the only widely-agreed definition of “fast enough” — and they’re measured on your customers’ devices, not yours.
What it is
Core Web Vitals are a set of three metrics measured on real user visits, each with a threshold at which the experience is considered good.
| Metric | Measures | Good | Poor |
|---|---|---|---|
| Largest Contentful Paint (LCP) | Loading — when the main content appeared | ≤ 2.5s | > 4.0s |
| Interaction to Next Paint (INP) | Responsiveness — input to visible response | ≤ 200ms | > 500ms |
| Cumulative Layout Shift (CLS) | Visual stability — how much moved unexpectedly | ≤ 0.1 | > 0.25 |
Assessed at the 75th percentile. A page passes only when 75% of visits meet the threshold — and all three must pass. See Percentiles in Performance for why that choice matters more than it looks.
[CHECK: the metric set and thresholds have been stable, but INP replaced First Input Delay in March 2024 and the set has changed before — verify against web.dev before quoting.]
Field, not lab
The defining property: Core Web Vitals are field metrics. The numbers Google uses come from real Chrome users on real devices and connections, aggregated over 28 days.
That has consequences people trip over:
- Your Lighthouse score is not your Core Web Vitals. Lighthouse is a simulated single run. It’s a diagnostic, not the measurement — see Field vs Lab Data
- Improvements take weeks to appear, because the window is rolling
- INP cannot be measured in a lab at all, meaningfully. It needs real interactions from real users
- Your device flatters you. A developer laptop on office broadband is not the 75th percentile of your traffic
Why they’re worth caring about
Two separate arguments, and it’s worth keeping them apart.
The ranking argument is real but modest. Page experience is a signal among many, and it’s usually a tiebreaker rather than a driver. Anyone promising traffic transformation from a CLS fix is selling something.
The conversion argument is the substantial one. Slow pages lose users before they see anything, and unresponsive ones lose them at the point of intent. But the relationship is not a fixed exchange rate — see Performance and Conversion for how to estimate it on your own site rather than borrowing a figure from a case study.
In plain terms: treat Core Web Vitals as a health check with agreed thresholds, not as a score to optimise. Passing all three at p75 means you’ve stopped losing people to speed; it doesn’t mean speed is now a growth lever.
What each is really detecting
Each metric is a proxy, and knowing what it proxies tells you where to look:
- LCP is mostly a network and discovery problem. The main image or heading is late because the server was slow, the resource was found late, or something blocked rendering — The Critical Rendering Path, Render-Blocking Resources
- INP is a main thread problem. Something is occupying the one thread that also renders — Long Tasks and Blocking, Third-Party Scripts
- CLS is a reserved space problem. Something arrived and pushed content around because nothing held its place — Image Optimisation, Font Loading
Three different causes, three different fixes, and almost no overlap between them. A site can be excellent on one and terrible on another.
Where to look at them
- Chrome User Experience Report (CrUX) — the underlying dataset, queryable in BigQuery
- Search Console — page groups passing and failing, which is the report stakeholders will see
- PageSpeed Insights — field data and a lab run side by side, on one URL
- Your own Real User Monitoring — the only version segmentable by device, template, country and traffic source, and the only one that updates today rather than in four weeks
The last one is what you actually work from. The public sources tell you whether you pass; RUM tells you who’s failing and why.