Core Web Vitals Explained
Short answer
Core Web Vitals are three metrics Google uses to measure page experience: Largest Contentful Paint should be under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1. They are measured on real users, mostly on mobile, so the number that matters is field data from actual visitors rather than a lab score.
Published 2026-09-05 · Updated 2026-09-05
The three metrics
Largest Contentful Paint measures how long until the biggest visible element, usually the hero image or headline, finishes rendering. It is a proxy for how long the page feels blank.
Interaction to Next Paint measures responsiveness: when a user taps something, how long before the page visibly reacts. It replaced First Input Delay in 2024 and is stricter, because it measures every interaction rather than only the first.
Cumulative Layout Shift measures unexpected movement. It is the metric behind the experience of reaching for a button and having an ad load above it, moving the button under your finger.
What typically fails, and why
On Indian sites the causes are consistent enough to be predictable.
- LCP: oversized hero images, images not in modern formats, fonts blocking render, slow server response
- INP: heavy JavaScript on the main thread, third-party chat and tracking scripts, oversized frameworks doing work on load
- CLS: images and embeds without width and height attributes, banners injected above content, web fonts swapping and reflowing text
Lab data versus field data
A PageSpeed Insights score of 95 on a fast desktop connection is not the number Google uses. Core Web Vitals assessment is based on the Chrome User Experience Report: real visits from real devices, which in India means a lot of mid-range Android phones on variable mobile connections.
Always check the field data section in PageSpeed Insights or the Core Web Vitals report in Search Console. Optimising to a lab score while field data stays red is a common and expensive mistake.
How much do they matter for rankings?
They are a genuine ranking signal but a modest one. A slow page with the best answer will usually still outrank a fast page with a worse answer. Core Web Vitals act more as a tiebreaker between comparable pages than as a primary factor.
The stronger argument is commercial rather than algorithmic. Slow pages lose visitors before they read anything, and that cost is paid on every channel (paid, organic, social and direct) simultaneously.
The fixes that usually work
Serve images in modern formats at the size they are actually displayed, and set explicit dimensions so nothing shifts. Preload the LCP image. Load fonts with font-display swap and a sensible fallback stack. Defer non-essential JavaScript. Audit third-party scripts and remove the ones nobody uses: an abandoned chat widget or an old tracking pixel is pure cost.
For most sites, image handling and third-party scripts account for the large majority of the problem. Framework-level optimisation matters far less than people expect.
Core Web Vitals thresholds
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| Largest Contentful Paint | ≤ 2.5s | 2.5s – 4.0s | > 4.0s |
| Interaction to Next Paint | ≤ 200ms | 200ms – 500ms | > 500ms |
| Cumulative Layout Shift | ≤ 0.1 | 0.1 – 0.25 | > 0.25 |
Related questions
Will fixing Core Web Vitals improve our rankings?
Possibly a little, but do not expect it to be transformative on its own. The reliable benefit is conversion: faster pages keep more visitors, which improves results across every channel simultaneously.
Why is our PageSpeed score good but Search Console shows a failure?
Because they measure different things. PageSpeed's score is a lab simulation; Search Console reports field data from real Chrome users. Real users on mid-range Android phones over mobile networks produce very different numbers from a simulated desktop test.
Do Core Web Vitals apply to mobile and desktop separately?
Yes, and they are assessed separately. Mobile is generally the harder set to pass and, for most Indian sites, the more important one given traffic composition.
How long before improvements show in Search Console?
The report uses a rolling 28-day window of field data, so meaningful change usually takes three to four weeks to appear after a fix ships, even when the improvement is immediate for users.