If you’ve opened Google Search Console or PageSpeed Insights and found a warning about Core Web Vitals, it can be hard to know what to do with it. This guide is for site owners and marketers who want to understand what those three scores measure, what counts as good, where to read their own numbers and what Google does and doesn’t claim about rankings.
Core Web Vitals are three measurements of real visits to your pages: LCP for loading, INP for responsiveness and CLS for visual stability[1]. Good means LCP of 2.5 seconds or less, INP of 200 ms or less and CLS of 0.1 or less[2]. Google strongly recommends good scores and says they line up with what its ranking systems reward, but it also says good scores don’t guarantee top rankings[4][5].
What the three Core Web Vitals metrics measure
Each metric covers one part of how a page feels to a real person[1].
LCP: Largest Contentful Paint
LCP is about loading. It records how long it takes for the largest piece of content in the viewport to appear. It’s a rough stand-in for the moment a visitor feels the page has actually arrived.
INP: Interaction to Next Paint
INP is about responsiveness. It looks at how quickly the page reacts visually when someone taps, clicks or presses a key[7]. INP is described as the successor to FID (First Input Delay), the older responsiveness metric, so if you still see FID mentioned in older guides, INP is the one to watch now[7].
CLS: Cumulative Layout Shift
CLS is about visual stability. It adds up unexpected movement on the page, like a button jumping down just as you go to tap it because an image or banner loaded late. Unlike the other two, it isn’t measured in seconds. It’s a unitless score.
The thresholds
Google publishes a good boundary for each metric[2], and a poor boundary beyond which a page is clearly struggling[3]. Anything between the two is labelled needs improvement[3].
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP | 2.5 s or less | 2.5 to 4 s | Over 4 s |
| INP | 200 ms or less | 200 to 500 ms | Over 500 ms |
| CLS | 0.1 or less | 0.1 to 0.25 | Over 0.25 |
Two details trip people up. First, the scores are not judged on your average visit. Assessment uses the 75th percentile of page loads, which means that to be rated good, at least three in four visits need to hit the good threshold[1]. A fast experience for most people doesn’t help if a quarter of visits are slow.
Second, mobile and desktop are assessed separately[1]. A page can pass on desktop and fail on phones. And a page only passes overall if all three metrics are good[1]. Two out of three isn’t a pass.
Tip
Look at the mobile result first if your visitors mostly browse on phones. It’s the one that reflects most of your real traffic.
Field data and lab data
This is the distinction that explains most of the confusion people have when two tools show different numbers for the same page.
Field data is collected from real users as they visit your site. Lab data comes from a simulated page load in a controlled environment. All three Core Web Vitals are primarily field metrics, and only field data gives the full picture of what visitors experience[1].
Lab tools are useful for testing, but they have limits, particularly for INP. INP depends on what real people actually tap and click, and a simulated load doesn’t interact with the page the way they do. That’s why Total Blocking Time (TBT) is used as a proxy in lab tests[1]. Treat a TBT figure as a hint about responsiveness, not as your INP score.
PageSpeed Insights shows both kinds of data. The field data comes from the Chrome UX Report (CrUX) and covers the previous 28 days. The lab data is a simulated Lighthouse load of the page[6]. If the two disagree, that’s expected. The field number reflects real visitors over a month. The lab number reflects one test run under fixed conditions.
Good to know
A fresh change to your site won’t show up in field data straight away, because the 28-day window is still mixing in older visits.
Where to read your scores
There are two places most site owners will use. They answer slightly different questions.
PageSpeed Insights
Paste a URL into PageSpeed Insights and run the test. You get field data from CrUX for the previous 28 days alongside lab results from a simulated Lighthouse load[6]. Use it to look at one page at a time.
The Core Web Vitals report in Google Search Console
In Google Search Console, open the Core Web Vitals report. It uses field data over a rolling 28 days, and it reports mobile and desktop apart[3]. Instead of one page, it groups URLs together. A group takes the status of its worst metric, so one weak metric pulls the whole group down[3].
That grouping is why you can open a single page in PageSpeed Insights, see it passing, and still find a similar page inside a failing group in Search Console. Start with the report to spot which groups of URLs are affected, then use PageSpeed Insights to look at individual pages within them.
Watch out
Don’t read a good lab score as proof that your Core Web Vitals pass. The assessment that counts is the field data, split by device, at the 75th percentile[1].
What Google says about rankings
The honest answer sits between two extremes: it isn’t hype, and it isn’t nothing.
Google Search Central strongly recommends that site owners achieve good Core Web Vitals, and says they align with what its core ranking systems seek to reward[4]. That’s a clear signal that they matter. But Google also says there is no single page experience signal[5]. Page experience is made up of more than Core Web Vitals.
Google is also explicit that good scores do not guarantee top rankings[5]. Its documentation notes that the most relevant content can still show up in results even when the page experience is weaker[5]. A page that answers the search better can still show ahead of a faster page that answers it worse.
So the practical reading is this. Good Core Web Vitals are worth having, because they describe a better experience for the people who visit and they’re in line with what Google says it wants to reward. They are not a switch that moves you up a results page on their own, and Google doesn’t describe them as a fixed-weight ranking factor.
FAQs
What are Core Web Vitals in simple terms?
They’re three measurements of how a page feels to real visitors: how fast the main content loads (LCP), how quickly the page responds to taps and clicks (INP) and how stable the layout is while loading (CLS)[1].
What is a good LCP, INP and CLS score?
Does INP replace FID?
INP is described as the successor to FID, the earlier responsiveness metric[7]. It’s the metric to check now.
Do Core Web Vitals affect my rankings?
Why does PageSpeed Insights show two different sets of results?
One is field data from real users, taken from the Chrome UX Report over the previous 28 days. The other is lab data from a simulated Lighthouse load[6]. They measure different things, so they often don’t match.
What does the Core Web Vitals report in Search Console show?
Can a page pass on desktop but fail on mobile?
Yes. The two are assessed separately, so you can pass on one and fail on the other[1]. Check both before you decide a page is fine.
What is the 75th percentile and why does it matter?
It means Google judges a page by the experience that three in four visits meet or beat, not by the average[1]. If a quarter of visits are slow, that can be enough to stop a page passing.
Where to go from here
Open the Core Web Vitals report in Google Search Console, note which metric is dragging each failing group down, then check a sample page from that group in PageSpeed Insights. If you’d like a second pair of eyes on what the numbers are telling you, you can get in touch with Oxford Impulse at https://oxfordimpulse.com/contact/ .
Sources
- Web Vitals | Articles | web.dev web.dev
- How the Core Web Vitals metrics thresholds were defined web.dev
- Core Web Vitals report – Search Console Help support.google.com
- Understanding Core Web Vitals and Google search results developers.google.com
- Understanding Google Page Experience developers.google.com
- About PageSpeed Insights developers.google.com
- Interaction to Next Paint (INP) web.dev
