The three metrics and what each one catches
Each metric covers a different way a page can feel wrong, and they fail independently. A page can load fast and still lurch under the reader's thumb; a page can be perfectly stable and take four seconds to show anything.
| Metric | Covers | Good | Needs work above |
|---|---|---|---|
| LCP | Loading | ≤ 2.5 s | 4.0 s |
| INP | Responsiveness | ≤ 200 ms | 500 ms |
| CLS | Visual stability | ≤ 0.1 | 0.25 |
Largest Contentful Paint marks the moment the biggest thing in the viewport finishes rendering — usually a hero image or a heading block. It is a proxy for "the page looks like it has arrived", which is why it beats older marks like first paint: a blank frame painting quickly is not a page loading quickly.
Interaction to Next Paint replaced First Input Delay as a stable Core Web Vital in March 2024, and the replacement mattered. FID measured only the delay before the first interaction was handled, which flattered pages that answered the first tap quickly and then bogged down. INP looks at the full latency of interactions across the visit and reports close to the worst of them.
Cumulative Layout Shift measures content moving after it has been painted. It is the metric behind the universal experience of reaching for a link and hitting an ad that arrived underneath it. Because it is a score rather than a duration, a single bad shift late in the page can dominate the number.
Scored at the 75th percentile, on field data
This is the part that catches teams out. Assessment uses the 75th percentile of page loads over a rolling 28-day window, segmented separately for mobile and desktop. A comfortable median with a slow tail still fails — by design. The metric is about the quarter of visitors having the worst time, not the typical one.
It also means the data is field data, gathered from real visits, not a lab run. Lab tools are diagnostic instruments: they tell you which resource is holding up the render, and they are the right tool for finding a cause. They are not the assessment, and a green lab score alongside a failing field assessment is not a contradiction — it means your real visitors are not on the machine you tested from.
What actually moves each metric
The causes are unglamorous and repeat across sites. Most of the work is deciding what the browser must have before the first meaningful paint and refusing everything else a place in that queue.
| Metric | Usual cause | Usual fix |
|---|---|---|
| LCP | Slow server response | Cache the document; cut redirect chains |
| LCP | Hero image discovered late | Preload it; never lazy-load it |
| LCP | Render-blocking CSS or fonts | Inline critical CSS; use font-display |
| INP | Long JavaScript tasks on the main thread | Break them up; defer non-essential work |
| INP | Heavy third-party scripts | Load them late, or drop them |
| CLS | Images and embeds with no dimensions | Set width and height, or aspect-ratio |
| CLS | Fonts swapping and reflowing text | Match fallback metrics; preload the face |
| CLS | Banners injected above content | Reserve the space before it fills |
Third-party scripts deserve singling out, because they are the most common cause of an INP problem and the one nobody owns. Every tag added for analytics, chat, testing or consent competes for the same main thread the reader's tap needs. The audit question worth asking is not whether each is useful but what it costs at the 75th percentile.
Where page experience sits among signals
Google says its core ranking systems use Core Web Vitals, but there is no single “page experience signal”. Relevance still comes first, and good Core Web Vitals do not guarantee a top ranking.
Prioritize user-facing problems, especially on important templates, without treating a passing threshold as a ranking guarantee. A relevant page with a poor experience can still rank; a fast page that misses the query does not become relevant because it is fast.
A working order of operations
If you are starting from a failing assessment, this sequence avoids the most common wasted effort — tuning what is already passing, or fixing a page that gets no traffic.
- Read the field data first, split by mobile and desktop. Mobile usually fails alone, and fixing desktop changes nothing.
- Find which metric fails and on which page groups. Templates fail together; one URL rarely tells you much.
- Reproduce the cause in the lab, on a throttled connection. The lab tells you what is slow; the field told you that it matters.
- Fix the largest single contributor and ship it. Partial improvements are how these move — there is rarely one switch.
- Wait out the 28-day window before judging. The assessment is a trailing average, so a fix shipped today shows up gradually.