Core Web Vitals
Core Web Vitals are the three metrics Google uses to describe how a page feels to the person loading it: how fast the main content appears, how quickly the page answers a click, and whether things jump around while it loads.
| Metric | Measures | Good | Poor |
|---|---|---|---|
| LCP — Largest Contentful Paint | Loading | ≤ 2.5 s | > 4 s |
| INP — Interaction to Next Paint | Responsiveness | ≤ 200 ms | > 500 ms |
| CLS — Cumulative Layout Shift | Stability | ≤ 0.1 | > 0.25 |
A page passes when the 75th percentile of real visits is in the good band for all three. INP replaced First Input Delay (FID) in March 2024; FID only timed the first interaction's input delay, INP times the slowest interactions across the whole visit, through to the next frame painted.
Field data and lab data
The numbers come from two places, and most confusion about Core Web Vitals is these two disagreeing.
- Field data is measured in real users' Chrome browsers and published in the Chrome UX Report (CrUX) as a rolling 28-day window. PageSpeed Insights shows it at the top as "Discover what your real users are experiencing", and Search Console groups URLs by it. This is the assessment that counts.
- Lab data is one Lighthouse run: a single load, on one machine, with simulated throttling. It is reproducible and it explains why — which script blocked the main thread, which image was the LCP element — but it is not what real users got.
A lab run can be green while field data fails (your laptop and CDN cache are faster than your users' phones) or the reverse (the slow page only appears for logged-in users, whom Lighthouse never is).
Where Lighthouse fits
Lighthouse's Performance score is not a Core Web Vitals score. Since Lighthouse 10 it is a weighted average of five lab metrics:
| Metric | Weight |
|---|---|
| Total Blocking Time | 30% |
| Largest Contentful Paint | 25% |
| Cumulative Layout Shift | 25% |
| First Contentful Paint | 10% |
| Speed Index | 10% |
INP is absent because a page-load run never clicks anything. Total Blocking Time stands in for it: long main-thread tasks that block input during load are the same tasks that make interactions slow later. To measure INP in the lab, script the interactions in a Lighthouse user flow and run it in timespan mode.
Reading the report
The scores start the conversation; the audits under them settle it. In
a Lighthouse report each failed audit carries an estimated saving and
the URLs or elements behind it — "Reduce unused JavaScript, 1.9 s,
vendor.js" is something an engineer can act on, "Performance 41" is
not. The Lighthouse report viewer turns the
JSON from the CLI, Lighthouse CI or the PageSpeed Insights API into
that list, ordered by savings, with a Markdown summary for the pull
request.
When the person who decides what gets fixed is a client or a PM, send them the report rather than a screenshot of four circles — and send a link that will still work next month, which Lighthouse CI's public links do not (why).
Related
- Lighthouse report viewer — Lighthouse or PageSpeed Insights JSON to a readable report
- Lighthouse CI link expired — temporary-public-storage, and keeping the link
- HTML report — the format most tools write for humans
- Flame graph — the other half of finding what blocks the main thread
- Glossary — every term