Three metrics, three thresholds
Each answers a question a visitor asks without thinking: has it loaded, does it respond, does it stop moving.
- Anything between good and poor is Needs improvement, which counts as not passing. You pass only if all three land in the good band.
- INP superseded First Input Delay in March 2024. FID measured only the delay before the first interaction; INP measures full response time across the whole visit — harder, and fairer.
- CLS annoys users most and costs least to fix: reserve height for images, ads and embeds, and stop injecting banners above content that's already rendered.
- Each metric has its own page — LCP, INP and CLS — with causes and fixes.
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| LCP — Largest Contentful Paint | How long until the biggest visible element — usually a hero image or headline — renders. | ≤ 2.5s | > 4.0s |
| INP — Interaction to Next Paint | How long the page takes to visibly respond to a tap, across every interaction in the visit. | ≤ 200ms | > 500ms |
| CLS — Cumulative Layout Shift | How much the layout jumps while loading. A ratio, not a time. | ≤ 0.1 | > 0.25 |
The 75th percentile rule, and why your score lies
Google doesn't measure your site on a test machine. It uses the Chrome User Experience Report — CrUX — real measurements from real Chrome users on real devices and networks, over a rolling 28-day window. Your assessment is the 75th percentile of that distribution: the value three-quarters of visits came in under.
So a page passes LCP when 75% of real visits rendered the main content within 2.5 seconds. Your fastest quarter contributes nothing; your slowest quarter is allowed to be terrible. Everything hinges on the visitor at the three-quarter mark.
Compare that to PageSpeed Insights. The big 0-to-100 number is the Lighthouse score — lab data: one simulated load on a throttled mid-tier mobile profile. Useful for debugging, and not what Google uses for ranking. The field data sits above it, and with enough traffic that section is the only one that counts.
A 95 in the lab and a fail in the field is an ordinary result. So is the reverse.
Why an Indian site fails on a network its founder never uses
Here's the concrete version, and it's why this gets misdiagnosed so often in India.
You check the site in a Bangalore office on fibre, on a recent iPhone, everything warm in cache. It renders instantly. PageSpeed Insights says 92. You conclude speed isn't your problem.
Your 75th-percentile visitor is on a three-year-old Android in Indore, on a connection that's fine for video and bad for a page shipping 2MB of JavaScript, with an ad script and three tracking pixels queued ahead of your hero image. Their LCP can sit past four seconds on a page that renders in under two on your desk — and theirs is the experience Google records, not yours.
The gap is widest for the sites that most need to close it: ecommerce and D2C brands whose buyers sit across tier-2 and tier-3 cities on mid-range phones. If your traffic skews mobile and wide, assume the field data is worse than anything you can reproduce locally.
How much this actually affects rankings
Less than the tooling implies. Core Web Vitals are a real ranking input, but a small one — closest to a tiebreaker between results of comparable relevance. A fast page about the wrong thing does not outrank a slow page about the right thing.
Which is why we won't sell a Core Web Vitals project to a site whose real problem is four thin pages and no links. Fixing CLS on a page nobody can find is theatre.
The genuine case here is commercial, not algorithmic. Slow pages lose people before the page finishes arriving, and on mobile checkout that loss compounds at every step. That's revenue you can measure without arguing about ranking weights.
Where to look: the Core Web Vitals report in Search Console groups URLs by template and shows which page type fails, split by mobile and desktop. Mobile is where failures live and mobile is what gets indexed, so start there. Then run PageSpeed Insights on one URL per failing group — one diagnosis per template, not per page. Red across a whole page type is Core Web Vitals work, usually a rendering and asset problem rather than a hosting one.