LCP, CLS, and INP are the signals that matter. Know how they are calculated, where to access real user data, and what fixes move scores the quickest.
Watch
Core Web Vitals are three metrics Google uses to describe real-world page experience: Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. Each has a threshold, and each is assessed at the 75th percentile of real visits rather than on a single test run.
That percentile is why your score does not match what you see in a browser. You are looking at one load on a fast connection; the assessment is looking at the visit that was worse than 75% of the others.
The three metrics and their thresholds
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| LCP | Time until the largest content element in the viewport is rendered | 2.5s or less | Over 4.0s |
| INP | Latency from an interaction to the next frame painted, across the visit | 200ms or less | Over 500ms |
| CLS | Sum of unexpected layout shift during the page lifespan | 0.1 or less | Over 0.25 |
Google's definition of the assessment point is worth quoting because it is where most confusion starts: "a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices". Mobile and desktop are separate assessments. A site can pass on one and fail on the other, and mobile is usually the one that fails.
INP replaced First Input Delay, becoming a stable Core Web Vital in 2024. If a tool or an article still reports FID, it is out of date. The difference is not cosmetic: FID measured only the delay before the first interaction was processed, so a site could score well on it while every subsequent click felt slow. INP measures the full latency of interactions across the visit, which is a much harder test to pass.
Field data and lab data are different numbers
Open PageSpeed Insights on any URL and you get two sets of results that frequently disagree. Both are correct.
- Field data comes from the Chrome User Experience Report: aggregated measurements from real Chrome users over a rolling 28 day window. This is what the Core Web Vitals assessment uses, and it only exists for URLs with enough traffic to reach the reporting threshold.
- Lab data comes from Lighthouse running a single simulated load on a throttled connection. It is repeatable and diagnostic, and it is not what you are assessed on.
Two consequences people trip over. A low-traffic page has no field data at all, so it inherits its origin-level assessment. And CLS in the lab is usually optimistic, because a synthetic run does not scroll, does not accept a cookie banner and does not wait for the lazy-loaded advert that pushes the article down.
Pull your own field numbers
The web interface is fine for one URL. For a list of templates, query the API and read the field metrics directly:
curl -s "https://www.googleapis.com/pagespeedonline/v5/runPagespeed
?url=https://example.com/&strategy=MOBILE"
| python3 -c "
import json,sys
d = json.load(sys.stdin).get('loadingExperience', {}).get('metrics', {})
for k, v in d.items():
print(k, v['percentile'], v['category'])
"The output gives the 75th percentile value and the good/needs-improvement/poor bucket for each metric, which is the same data the assessment uses. Add &key= with an API key if you are running it across more than a handful of URLs, or you will be rate limited. If loadingExperience comes back empty, that URL has insufficient field traffic and you are working from lab data whether you like it or not.
The Core Web Vitals report in Search Console groups URLs by similarity, which is the view worth acting on. Fixing one template fixes every URL in the group, and that is nearly always where the leverage is rather than in individual pages.
What usually causes each failure
LCP is dominated by two things: server response time, and how late the largest element is discovered. A hero image loaded by JavaScript, or one without a fetchpriority="high" hint, is found by the browser far too late. Before optimising images, check TTFB, because if the origin takes 900ms nothing downstream will save you.
INP is almost always long JavaScript tasks blocking the main thread while the user is trying to interact. Third-party tags are the usual suspect, and the honest fix is removing some of them rather than deferring them into a queue that still has to run. Breaking up the tasks that block interaction is a separate exercise with its own profiling steps.
CLS is the cheapest of the three to fix and the most often ignored. Set explicit width and height on images and iframes, reserve space for advert slots and embeds, and stop injecting banners above existing content after load. There is more detail on each of these in the changes that actually shift the numbers.
How much is passing actually worth
Less in rankings than the case studies imply, and more in revenue than most technical teams expect. That is the position, and it is worth being straight about it because the two get conflated constantly.
As a ranking input, Core Web Vitals is one small signal among many. Fixing a poor LCP on a page that answers a query badly will not make it rank, and we have never seen speed work alone move a page across a competitive SERP. Where it does show up is on pages already competing closely, and as a floor: a genuinely slow site loses positions it should hold.
The business case is stronger and better evidenced. In Vodafone's A/B test published on web.dev, a 31% improvement in LCP produced an 8% increase in total sales, an 11% uplift in cart-to-visit rate and a 15% uplift in lead-to-visit rate. That is a controlled test with a named company behind it, which is rarer in this field than the volume of statistics suggests. Treat unattributed figures about milliseconds and conversion rates with suspicion; most of them trace back to nothing you can check.
Frequently asked questions
What are Core Web Vitals in simple terms?
Three measurements of how a page feels to use: how quickly the main content appears, how quickly it responds when you interact with it, and how much it jumps around while loading. Google collects them from real Chrome visits rather than from a test.
Are Core Web Vitals still relevant?
Yes, though their weight as a ranking factor is modest and always has been. They remain the clearest shared vocabulary between an SEO team and an engineering team for describing performance, and that alone makes them worth tracking even if you discount the ranking effect entirely.
How do I pass the Core Web Vitals assessment?
All three metrics have to be at or under their good threshold at the 75th percentile, for the device type being assessed. Work at template level rather than URL level, fix CLS first because it is cheap, then LCP, then INP. Field data moves on a 28 day rolling window, so expect roughly a month before a deployed fix is fully reflected.
What is a good CLS score?
0.1 or less. Above 0.25 is classed as poor. Unlike the other two it is not a time measurement, it is a unitless score combining how much of the viewport shifted and how far it moved, and the common causes are short and well understood.
If your Search Console report shows failing groups and you are not sure which template each one maps to, that mapping is usually the whole job. We work through it as part of a performance and indexability audit, using field data rather than Lighthouse scores.
Infographic
