The three metrics
Core Web Vitals are three measurements of what using a page feels like. Each has a published threshold for "good".
| Metric | Measures | Good |
|---|---|---|
| LCP — Largest Contentful Paint | How long until the main content appears | ≤ 2.5s |
| INP — Interaction to Next Paint | How quickly the page responds when you interact | ≤ 200ms |
| CLS — Cumulative Layout Shift | How much the layout jumps around | ≤ 0.1 |
INP replaced FID (First Input Delay) as a Core Web Vital in March 2024. If you are reading advice that discusses FID, it predates that change and is likely stale in other respects too.
Two structural facts matter more than the definitions.
The threshold is measured at the 75th percentile. Not the average. Three-quarters of real visits must meet it. One slow page type dragging a quarter of your traffic will fail the assessment even if the median looks healthy — and an average hides exactly that.
Assessment is per URL, grouped by similar pages. A fast homepage does not rescue slow product pages.
Lab data and field data are different things
This is the single most common source of confusion, and it explains most "my score says 100 but Search Console says I'm failing" reports.
Lab data is a simulated load: one device, one connection, one moment. Lighthouse and the PageSpeed Insights performance score are lab data. Useful for debugging, because it is repeatable and it tells you what to change.
Field data is what actually happened to real visitors — collected from Chrome users over a rolling 28-day window, and published as the Chrome UX Report (CrUX). Search Console's Core Web Vitals report uses field data.
They disagree constantly, for good reasons: real visitors are on worse devices and slower networks than a lab test, and INP in particular cannot be meaningfully measured in a lab because it requires someone to actually interact with the page.
Field data is the one that counts. Lab data is how you find the cause; field data is how you know whether you fixed it. And because the field window is 28 days rolling, a fix deployed today will not show fully for about four weeks — which is long enough that people often conclude a working fix did nothing.
What actually moves LCP
LCP is usually an image, a heading, or a large block of text — whichever is the biggest thing visible without scrolling.
The causes, in the order they are usually worth checking:
- Slow server response. Everything downstream waits on the first byte. Caching and hosting quality dominate here, and no amount of front-end work compensates for a slow origin.
- Render-blocking CSS and JavaScript. The browser will not paint until it has processed them.
- The LCP image itself — unoptimised, wrong format, or larger than the space it occupies.
- Lazy-loading the LCP image. A genuinely common own-goal: lazy loading is applied site-wide, including to the one image that defines LCP, which delays the exact thing being measured. The image above the fold should load eagerly.
Preloading the LCP image and serving modern formats are the usual quick wins. Fixing an overloaded server is the slow one, and often the real one.
What actually moves INP
INP measures the delay between an interaction and the next visual update. It is almost always JavaScript occupying the main thread when the user does something.
The usual causes:
- Heavy third-party scripts — tag managers, chat widgets, analytics, A/B testing tools
- Long tasks that block the main thread instead of yielding
- Expensive event handlers doing work that could wait
INP is where accumulated third-party scripts show up. Every tag added "just to try" costs main-thread time, and the cost is paid on every interaction by every visitor.
It is also the hardest of the three to fix, because the answer is frequently "remove something" — and something was added for a reason somebody still believes in.
What actually moves CLS
CLS is the most tractable of the three, because the causes are few and specific:
- Images and video without dimensions. The browser cannot reserve space it does not know about. Set
widthandheight, or useaspect-ratio. - Ads, embeds and iframes injected into flowing content. Reserve the space.
- Web fonts swapping and re-flowing text.
- Content inserted above existing content — cookie banners, notification bars — after the page has painted.
The pattern is one thing: something arrived late and pushed what was already there. Reserve space in advance and the shift disappears.
Are Core Web Vitals a ranking factor?
Yes, and the honest framing matters.
They are part of Google's page experience signals. They are a tiebreaker, not a lever. A fast page does not outrank a more relevant slow one. Where two pages are comparably relevant and authoritative, experience can separate them.
What that means practically: if your pages are not ranking, Core Web Vitals are rarely the reason, and a project to fix them will not fix relevance. Where they genuinely pay is conversion — a page that responds quickly loses fewer people before they act, and that is worth doing regardless of what Google does with the numbers.
Be suspicious of anyone selling Core Web Vitals work as a ranking fix. It is real engineering with real user benefit, sold honestly as that.
How to measure yours
- Search Console → Core Web Vitals. Field data, grouped by page type. Start here: it tells you which *group* of pages is failing, which is the question that matters.
- PageSpeed Insights on a specific URL. Shows field data at the top when available, and lab diagnostics underneath. The lab section tells you what to change.
- Chrome DevTools → Performance. For INP specifically, record while interacting. This is the only way to see which script is blocking.
- After a fix, wait. The field window is 28 days rolling. Judging a fix after three days tells you nothing.
Frequently asked questions
What are the Core Web Vitals thresholds?
LCP at or under 2.5 seconds, INP at or under 200 milliseconds, and CLS at or under 0.1. Each is assessed at the 75th percentile of real visits, not the average.
Why does PageSpeed Insights disagree with Search Console?
They measure different things. Search Console reports field data from real Chrome visitors over a rolling 28 days; the PageSpeed performance score is a lab simulation on one device and connection. Field data is what Google assesses.
Is INP the same as FID?
No. INP replaced FID as a Core Web Vital in March 2024. FID measured only the delay before the first interaction was processed; INP measures the full response time across interactions throughout the visit, which is a much harder bar.
How long before a fix shows up?
About four weeks. Field data uses a rolling 28-day window, so a deployed fix appears gradually as old slow visits age out of the dataset.
Find out what is actually slowing your pages down
Core Web Vitals are easy to measure and hard to move, because the number tells you a page is slow without telling you which of a dozen possible causes is responsible — and lab scores routinely point at the wrong one.
If you want the causes identified rather than guessed at, the Technical-Only Deep Dive diagnoses what is actually holding the site back — $697, one-off, no retainer.