Core Web Vitals in 2026: What Google Actually Measures and Why It Still Matters | Blog

# Core Web Vitals in 2026: What Google Actually Measures and Why It Still Matters

TL;DR: The Core Web Vitals metric set is LCP (loading), INP (responsiveness), and CLS (visual stability) — FID was formally retired and replaced by INP in March 2024, and the "good" thresholds (LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1, measured at the 75th percentile of real users) haven't changed since. Vitals still matter less as a direct ranking lever and more because they correlate tightly with bounce rate, conversion, and whether your JavaScript is doing something wasteful on the main thread.

The metric set, as it actually stands today

A lot of "Core Web Vitals" content circulating right now still talks about First Input Delay (FID) as if it's live. It isn't. Google's Chrome team deprecated FID and promoted Interaction to Next Paint (INP) to full Core Web Vital status on March 12, 2024, after running it as an experimental metric since 2022. If you're auditing a stack that still reports FID from an old dashboard or a stale analytics integration, that number is no longer part of how Google evaluates page experience.

The current three:

Metric	What it measures	Good	Needs improvement	Poor
LCP (Largest Contentful Paint)	Time until the largest visible content element renders	≤ 2.5s	2.5s–4.0s	> 4.0s
INP (Interaction to Next Paint)	Responsiveness across the full page lifespan, not just the first click	≤ 200ms	200ms–500ms	> 500ms
CLS (Cumulative Layout Shift)	Sum of unexpected layout movement during the page's lifecycle	≤ 0.1	0.1–0.25	> 0.25

Source thresholds: web.dev — How the Core Web Vitals thresholds were defined.

All three are scored at the 75th percentile of real-user visits (from Chrome UX Report data, not synthetic Lighthouse runs) at the URL or origin level. A page only "passes" Core Web Vitals if at least 75% of real visits hit the "good" band on all three metrics simultaneously.

Why INP replaced FID

FID only captured the delay before the browser started processing the first user interaction on a page — it said nothing about whether the tenth click, on a page loaded with a big client-side JS bundle, felt sluggish. INP samples every interaction (clicks, taps, key presses) for the duration of the visit and reports a single representative value — practically the interaction with the worst end-to-end latency, from input to the next visual frame the browser paints (with near-98th-percentile interactions on very interactive pages effectively dropped as outliers per Google's own INP calculation methodology).

For anything built with heavy client-side hydration — a common shape for a Next.js app with a lot of interactive client components — this matters more than FID ever did. A page can look instantly interactive on first load and still fail INP the moment a user opens a dropdown that triggers a large re-render.

How to actually measure it (not just Lighthouse)

Lighthouse and PageSpeed Insights give you lab data — a single synthetic run, useful for debugging, not for a Vitals verdict. Google's own ranking and reporting use field data from CrUX. If you want a real signal you control, instrument your own site with the official web-vitals JS library rather than relying only on PageSpeed Insights snapshots:

npm install web-vitals

// src/lib/reportWebVitals.ts
import { onCLS, onINP, onLCP, type Metric } from 'web-vitals';

function sendToAnalytics(metric: Metric) {
  const body = JSON.stringify({
    name: metric.name,
    value: metric.value,
    rating: metric.rating, // 'good' | 'needs-improvement' | 'poor'
    id: metric.id,
    navigationType: metric.navigationType,
  });

  // sendBeacon avoids blocking navigation/unload
  if (navigator.sendBeacon) {
    navigator.sendBeacon('/api/v1/public/vitals', body);
  } else {
    fetch('/api/v1/public/vitals', { body, method: 'POST', keepalive: true });
  }
}

onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onLCP(sendToAnalytics);

Call reportWebVitals() once from a top-level client component (in a Next.js App Router project, a small 'use client' wrapper mounted in the root layout works fine). This gets you real field data from your actual traffic mix — mobile carriers, low-end devices, real network conditions — instead of a single lab run from a data center.

Fixing each metric: the levers that actually move the number

LCP is almost always one of: a slow server response (TTFB), a render-blocking resource, or a late-discovered image/font.

Preload the actual LCP resource once you've identified it (DevTools Performance panel, or the element field in a CrUX/PageSpeed report):

<link rel="preload" as="image" href="/hero.avif" fetchpriority="high" />

Use fetchpriority="high" on the <img> itself for the LCP image, and never lazy-load it.
Serve modern formats (AVIF/WebP) and correctly sized responsive images (srcset/sizes) rather than shipping one oversized asset.

INP is almost always about the main thread being busy when the user interacts — long tasks, expensive re-renders, or synchronous work in event handlers.

Break up long tasks with scheduler.yield() (or setTimeout(fn, 0) as a fallback) so the browser can paint between chunks of work.
Debounce or defer non-critical work triggered by input (analytics calls, non-visual state updates) out of the critical interaction path.
Audit third-party scripts — tag managers, chat widgets, and A/B testing snippets are common INP killers because they run arbitrary JS on every interaction.

CLS is almost always missing dimensions or late-injected content.

Always set explicit width/height (or aspect-ratio) on images and embeds so the browser reserves space before the asset loads.
Reserve space for ads, cookie banners, and dynamically injected content rather than letting them push layout after the fact.
Use font-display: optional or preload web fonts to avoid FOIT/FOUT-driven reflow.

Does this still matter for SEO, or is it noise?

Google's own Search Central documentation is explicit that Core Web Vitals is one signal among many, and that it functions more as a tie-breaker than a primary ranking driver — two pages with comparable relevance and authority, the one with better page experience gets a nudge. Passing Core Web Vitals does not guarantee ranking, and failing them does not guarantee a penalty. For most sites, the more durable reason to fix Vitals isn't the SEO delta — it's that the same fixes (less main-thread JS, stable layouts, faster first paint) reduce bounce rate and improve conversion regardless of what the SERP does with them. If your team doesn't have the bandwidth to instrument, profile, and fix these issues in-house, that kind of performance engineering is exactly the sort of work a web development team would take on as a discrete, scoped project rather than an open-ended retainer.

What's next: soft navigations

One real limitation still unresolved as of 2026: LCP and INP are currently only measured on hard navigations (full page loads). Single-page apps that update the URL and DOM without a full reload — a common pattern in React/Next.js client-side routing — get almost no Vitals visibility for those in-app transitions. Chrome has been running origin trials for a "soft navigations" API (most recently through Chrome 147) to close this gap, but Google has stated it has no committed timeline for folding soft-navigation data into the CrUX report or search ranking signals. If your app is heavily client-routed, don't assume your Vitals dashboard is seeing the whole picture.

FAQ

Is FID still part of Core Web Vitals in 2026?

No. FID was fully replaced by INP as the official responsiveness metric on March 12, 2024. Any tool or dashboard still reporting FID as a "Core Web Vital" is using outdated terminology — the underlying data may still be collected for historical comparison, but it no longer factors into Google's Vitals assessment.

What's a "good" INP score?

200 milliseconds or less, measured at the 75th percentile of a page's real-user interactions. Between 200ms and 500ms is "needs improvement"; above 500ms is "poor."

Do Core Web Vitals directly affect Google rankings?

They're a ranking signal, not a primary one. Google's documentation frames Core Web Vitals as part of "page experience," which acts more as a tie-breaker between otherwise comparable pages than as a standalone ranking driver. Content relevance and authority still dominate.

Why does PageSpeed Insights show different numbers than my analytics?

PageSpeed Insights runs a single lab test from a fixed location and device profile. Your own web-vitals-based instrumentation reports field data from real visitors on real devices and networks — that's the data Google actually uses for Core Web Vitals assessment, and it's normal for the two to diverge, sometimes significantly, especially if your real traffic skews toward slower mobile connections than the lab environment simulates.