Core Web Vitals are the most misunderstood ranking factor in SEO, mostly because of one number: the Lighthouse score.
That score is a lab simulation. Google does not use it. What Google uses is field data — what actually happened to real people on real devices and real Indian mobile networks.
The two frequently disagree, and chasing the wrong one is how teams spend months optimising a number nobody ranks on. The wider technical context is in our SEO guide and technical SEO.
The three metrics
| Metric | Measures | Good | Needs work | Poor |
|---|---|---|---|---|
| LCP Largest Contentful Paint | How long until the biggest visible element has rendered | ≤ 2.5s | 2.5–4.0s | > 4.0s |
| INP Interaction to Next Paint | How quickly the page responds to taps and clicks | ≤ 200ms | 200–500ms | > 500ms |
| CLS Cumulative Layout Shift | How much the layout jumps while loading | ≤ 0.1 | 0.1–0.25 | > 0.25 |
INP replaced First Input Delay as a Core Web Vital in March 2024. If a tool or an old article still reports FID, it is out of date. INP is the harder metric of the two because it measures the full interaction, not just the delay before processing starts.
Field data vs lab data
| Field data | Lab data | |
|---|---|---|
| What it is | Real visits from real users, collected in the Chrome User Experience Report | A simulated load on a throttled connection |
| Where you see it | Search Console Core Web Vitals report, top of PageSpeed Insights | Lighthouse, the score out of 100 |
| Used for ranking | Yes | No |
| Good for | Knowing where you stand | Diagnosing why, and testing a fix before it ships |
| Lag | 28-day rolling window — changes take weeks to show | Instant |
Use lab data to find and fix problems. Use field data to judge whether it worked. And be patient: because the field window is a rolling 28 days, a fix shipped today will not be fully reflected for a month.
What usually causes each failure
LCP — slow server response, a hero image that is too large or loads late, render-blocking CSS and fonts, or the largest element being loaded by JavaScript. Fixing server response time and the hero image handles most cases.
INP — long JavaScript tasks blocking the main thread. Heavy third-party tags are the usual culprit: chat widgets, tag managers stacked with tags nobody audited, and analytics loaded synchronously. This is the metric most Indian sites now fail.
CLS — images and iframes without width and height attributes, ads and embeds injected above existing content, web fonts swapping in and reflowing text, and banners appearing after load. Almost all of it is fixed by reserving space in advance.
How much does it actually affect rankings?
Less than the amount of noise about it suggests, and more than nothing.
Google has consistently described page experience as a tiebreaker rather than a dominant factor — relevance comes first, and a fast page about the wrong thing will not outrank a slow page about the right one.
We are not going to quote a percentage, because no credible one exists.
What is not debatable is the conversion side. A page that jumps while someone is trying to tap a button loses that person regardless of where it ranks. That is the reason to fix these, and it does not require a ranking argument.
Where to start
- Open the Core Web Vitals report in Search Console. Mobile first — that is where the failures are. It groups URLs, so one fix usually clears a whole template.
- Fix by template, not by URL. Product pages, category pages, blog posts. Ten thousand URLs are usually four templates.
- Start with INP if you fail it. Audit your third-party tags and delete the ones nobody can name an owner for. This is almost always the cheapest large win.
- Then LCP: server response, then the hero image, then render-blocking resources, in that order.
- CLS last — it is usually the easiest, because it is mostly adding width and height attributes.
- Re-check field data after four weeks, not four days.
Where to go from here
Pull up your worst-performing template on a mid-range Android over mobile data, not on your laptop. That is the experience being measured.
Then audit your tag manager. On most sites we look at, a third of what loads is doing nothing anyone can explain.
Frequently asked questions
What are the three Core Web Vitals?
Largest Contentful Paint measures loading and should be under 2.5 seconds. Interaction to Next Paint measures responsiveness and should be under 200 milliseconds. Cumulative Layout Shift measures visual stability and should be under 0.1. All three are assessed at the 75th percentile of real user visits.
What replaced First Input Delay?
Interaction to Next Paint replaced First Input Delay as a Core Web Vital in March 2024. INP is a stricter measure because it captures the full time from a user interaction to the next visual update, rather than only the delay before the browser starts processing the input.
Why is my PageSpeed score good but Search Console says I fail?
Because they measure different things. The Lighthouse score out of 100 is a lab simulation and is not used for ranking. Search Console reports field data from real visits collected over a rolling 28-day window, and that is what Google uses. A fast lab result on a fast connection can coexist with poor real-world performance.
How much do Core Web Vitals affect rankings?
Google has consistently described page experience as a tiebreaker rather than a dominant factor, so relevance still comes first. We are not going to quote a percentage because no credible figure exists. The stronger argument for fixing them is conversion: a page that shifts while someone is tapping loses that person regardless of its position.
How long before improvements show in Search Console?
Around four weeks. Field data is collected over a rolling 28-day window, so a fix deployed today only becomes fully visible once the window has moved past the old data. Use lab tools to confirm the fix immediately, then wait for the field report to catch up.
We test on the phone your customers actually use
Field-data audits by template, prioritised by what will move the 75th percentile.