Core Web Vitals are three metrics Google uses to quantify how a page feels to a real person: how fast the main content appears, how quickly the page responds when you interact with it, and how much things move around while it loads.
They are a confirmed ranking signal, though a modest one — they rarely outweigh relevance. Their more direct value is commercial: slow, jumpy pages lose conversions regardless of where they rank.
The three metrics and their thresholds
| Metric | Measures | Good | Needs work | Poor |
|---|---|---|---|---|
| LCP — Largest Contentful Paint | When the largest visible element finishes rendering | ≤ 2.5s | 2.5s – 4.0s | > 4.0s |
| INP — Interaction to Next Paint | Responsiveness across all interactions on the page | ≤ 200ms | 200ms – 500ms | > 500ms |
| CLS — Cumulative Layout Shift | Unexpected movement of visible content | ≤ 0.1 | 0.1 – 0.25 | > 0.25 |
INP replaced FID
Interaction to Next Paint replaced First Input Delay as a Core Web Vital in March 2024. FID only measured the delay before processing the first interaction; INP measures the full latency of interactions throughout the page's life. It is a much harder test, and it is the metric most sites now fail.
The 75th percentile rule
Google does not score your average visitor. It takes the 75th percentile of real visits over a rolling 28-day window: 75% of visits must be at or better than the threshold. All three metrics must pass for the page to be assessed as "Good".
This has two practical consequences. First, your own experience of the site is nearly worthless as evidence — you are a fast-device, warm-cache, good-connection visitor sitting in the 20th percentile. Second, improving the median does nothing if the slow tail stays slow. Optimising for the worst quarter of your visitors is the whole game.
Lab data vs field data
| Field data (CrUX) | Lab data (Lighthouse) | |
|---|---|---|
| Source | Real Chrome users who opted in | A simulated load on a throttled device |
| Used for ranking | Yes | No |
| Speed of feedback | Slow — 28-day rolling window | Instant |
| Availability | Needs enough traffic; low-traffic pages show none | Always available |
| Includes INP | Yes | No — lab uses Total Blocking Time as a proxy |
Use lab data to iterate while fixing, because it responds immediately. Use field data to decide whether the fix actually worked, because that is what Google scores. Expect roughly four weeks before a real improvement is fully reflected in field data.
Fixing LCP
LCP is almost always a hero image, a heading, or a large text block. Identify the element first — PageSpeed Insights names it — because optimising anything else is wasted effort.
- 1Serve the LCP image in a modern format (AVIF or WebP), correctly sized for the viewport. Oversized hero images are the single most common cause.
- 2Preload it: <link rel="preload" as="image" href="…" fetchpriority="high">. Never lazy-load the LCP element — a lazy-loaded hero image is a self-inflicted LCP failure.
- 3Remove render-blocking resources in the <head>. Inline critical CSS; defer the rest. Third-party fonts and tag managers are frequent offenders.
- 4Cut server response time (TTFB). Anything above ~600ms means the problem is upstream of the browser — caching, database queries or hosting.
- 5Use font-display: swap so text renders immediately rather than waiting on a webfont.
Fixing INP
INP is a JavaScript problem in nearly every case. When a user taps something, the browser must run your event handler, recalculate layout and paint the result. If the main thread is busy, all of that queues.
- 1Break up long tasks. Anything over 50ms blocks interaction; split work and yield back to the main thread between chunks.
- 2Cut third-party scripts. Chat widgets, heatmaps, A/B testing tools and ad scripts are the usual suspects. Audit what each one earns you.
- 3Debounce expensive handlers — especially on input, scroll and resize events.
- 4Avoid large synchronous DOM updates in response to a click. Show immediate visual feedback, then do the heavy work.
- 5Defer hydration of below-the-fold components on JavaScript frameworks. Hydrating an entire page before the user can tap anything is a classic INP failure.
INP is measured across every interaction, and the reported value is close to the worst one. A page that responds instantly ninety-nine times and takes 800ms once will be scored on the 800ms.
Fixing CLS
CLS is the most fixable of the three, and the fixes are mostly mechanical.
- 1Set explicit width and height attributes on every image and video so the browser reserves space before the file arrives.
- 2Reserve space for ads, embeds and iframes with a min-height container. Ad slots that collapse then expand are the biggest single cause of bad CLS.
- 3Never insert content above existing content after load — cookie banners, promo bars and notification strips should overlay, not push.
- 4Preload webfonts and use size-adjust or a well-matched fallback to reduce the reflow when the real font swaps in.
- 5Avoid animating layout properties. Animate transform and opacity, which do not trigger layout.
Where to start
If you are triaging, work in this order:
- 1CLS first — cheapest fixes, immediate results, and it is the metric users notice most viscerally.
- 2LCP second — usually one image and a couple of render-blocking resources away from passing.
- 3INP last — genuinely the hardest, often requiring architectural change rather than configuration.
Set alerts below the threshold
Alert at roughly 80% of each limit — LCP 2.0s, INP 160ms, CLS 0.08. By the time the 75th percentile crosses the actual threshold, the regression has usually been live for weeks.
Measuring in Flux N Pro
The Core Web Vitals tool queries Google's PageSpeed Insights API for mobile and desktop, returning lab metrics plus field data where Google has enough traffic to report it. It is available free with no signup, and site-wide monitoring across your tracked pages is part of the paid plans.
Frequently asked questions
Are Core Web Vitals a ranking factor?
Yes, as part of Google's page experience signals, but a comparatively weak one. Content relevance and quality outweigh them. Treat Core Web Vitals as a tie-breaker between similarly relevant pages, and as a conversion issue in their own right.
Why does PageSpeed Insights disagree with Search Console?
PageSpeed Insights runs a lab test right now on a simulated device. Search Console reports field data from real users over a rolling 28-day window. Different data, different purpose — the field data is what counts for ranking.
What replaced First Input Delay?
Interaction to Next Paint (INP) replaced FID in March 2024. INP measures the latency of interactions across the whole page visit rather than just the first one, making it a considerably stricter test.
My page has no field data. What does that mean?
Not enough real Chrome users visited it for Google to report reliably. Google falls back to origin-level data or shows nothing. Use lab data for those pages and focus field-data work on your high-traffic templates.
How long before improvements show up?
Field data uses a rolling 28-day window, so expect around four weeks for a fix to be fully reflected. Lab scores update immediately, which is why they are useful during the work itself.
Try the Core Web Vitals Checker
Run the checks described in this guide against your own site — free, no account needed.
Open Core Web Vitals Checker →Get new guides by email
Occasional, practical SEO writing. No sequences, no upsells.