Technical SEO

Core Web Vitals in 2026: What Still Matters

INP replaced FID in 2024. What did that actually change, and what should you be measuring now?

Enric Ramos · · 9 min read
a computer screen with a rocket on top of it

Core Web Vitals is a real ranking signal. It's also a small one, smaller than most SEO blogs suggest. A page with great CWV and weak relevance loses to a page with mediocre CWV and strong relevance, every time. Internalize that before spending engineering weeks on LCP micro-optimization.

That said, CWV is the one performance signal Google has explicitly tied to ranking, and in competitive SERPs the small advantage compounds. This article covers what the current three metrics (LCP, INP, CLS) actually measure in 2026, where optimization effort converts to real improvement, and where it doesn't.

What changed since INP replaced FID

The March 2024 migration replaced First Input Delay with Interaction to Next Paint. It wasn't cosmetic. FID measured only the first click's delay, which missed most of the real-world interaction frustration. INP measures the worst interaction across the entire page visit, which is a fundamentally different signal.

Practical consequences:

  • Sites that passed FID easily often fail INP. A page with one fast first click but a laggy filter widget on scroll now fails.
  • Single-page apps with heavy hydration costs see bigger INP failures than expected.
  • Third-party widgets (chat, analytics, recommendation engines) that run on interaction now have visible CWV impact.

If your site passed CWV in 2023 and is borderline in 2026, INP is where the regression likely is.

The three metrics and their thresholds

All three use field data at the 75th percentile over a rolling 28-day window.

Metric Good Needs Improvement Poor
LCP ≤ 2.5 s ≤ 4.0 s > 4.0 s
INP ≤ 200 ms ≤ 500 ms > 500 ms
CLS ≤ 0.1 ≤ 0.25 > 0.25

A page passes Core Web Vitals when all three are "Good." There's no partial credit; two good and one borderline means you don't pass.

The p75 part matters. Your median user might see LCP of 1.8s, but if the slowest 25% see 3.5s, your CWV p75 is 3.5s and you fail. Optimization that only improves the median doesn't move the CWV needle.

Field data vs lab data

This is where most CWV optimization goes sideways. Lab tools (Lighthouse, PageSpeed Insights lab view, WebPageTest) measure synthetic runs on a controlled connection. They're useful for debugging a specific fix's impact. They're not what Google uses to rank.

Google uses field data from the Chrome User Experience Report (CrUX) — real Chrome users, real networks, real devices. CrUX aggregates at both the URL level (when there's enough traffic) and origin level. Sites with low traffic fall back to origin-level data; a bad URL on an otherwise-fast site might slip through on origin averages.

Practical implications:

  • A Lighthouse score of 100 with a failing CWV field score is common. Don't trust Lighthouse as your ranking signal.
  • Your real users' device mix dominates. If 60% of traffic is mobile on 4G, optimizing for desktop broadband is optimizing the wrong thing.
  • CrUX has a 28-day lag. A fix shipped today shows up in field data 4-6 weeks later.

Where to check field data: PageSpeed Insights shows both lab and CrUX side-by-side. CrUX Dashboard on Looker Studio gives you trend lines for your origin. GSC's Core Web Vitals report shows URL-group-level CWV status.

Fixing LCP: the four-phase breakdown

LCP has four time components. An LCP optimization that doesn't attribute time to each is guessing.

  1. Time to First Byte (TTFB) — server work + network from the user to your first response byte. Target: under 600ms at p75.
  2. Resource load delay — time from TTFB until the LCP resource starts being fetched. The killer: render-blocking CSS and JavaScript in <head>.
  3. Resource load time — time to download the LCP resource. Dominated by image size when LCP is an image.
  4. Element render delay — time from resource loaded until the browser paints it.

Break down your LCP in Chrome DevTools Performance panel (with "Web Vitals" enabled) or via the web-vitals JavaScript library. Attribute time to each phase.

Common LCP fixes, in order of typical impact:

  • Preload the LCP image. <link rel="preload" as="image" href="hero.webp" fetchpriority="high"> in the <head>. Only preload the actual LCP image; preloading non-LCP resources competes for bandwidth.
  • Eliminate render-blocking CSS. Inline critical CSS for above-the-fold, lazy-load the rest. For most sites this removes 100-400ms of LCP.
  • Use modern image formats. AVIF first, WebP fallback, JPEG as last resort. 50-70% size reduction typical. The full image SEO optimization playbook covers sizing, responsive srcset, and alt text alongside format choice.
  • CDN cache the LCP resources. Images served from edge with 1-year cache beat origin fetches every time for repeat visits. See how a CDN affects SEO performance for the full TTFB and cache-header breakdown.
  • Don't lazy-load the LCP image. loading="lazy" on the hero image is a classic LCP killer. Use loading="eager" (or omit; eager is the default) for above-the-fold images.
  • Optimize TTFB. If TTFB is over 600ms, nothing else matters. CDN, database query optimization, server-side rendering cost, external API calls in the render path — all fair game.

Fixing INP: the hidden interactions

INP failures are usually invisible on initial load. The page renders fast, the first click feels instant. The problem is on click #5, or on the filter toggle, or on the "load more" button.

INP's three phases:

  1. Input delay — time from user input until the event handler starts running.
  2. Processing time — the handler's actual work.
  3. Presentation delay — time from handler return until the browser paints the next frame.

The main thread being blocked when the user clicks is the #1 cause. Long tasks (>50ms) during interactive periods kill INP.

Where the hidden INP failures live:

  • Client-side rendered route transitions in SPAs. React/Vue apps that render large lists on filter changes produce 500ms+ INPs routinely. Virtualization (react-window, vue-virtual-scroller) is the fix.
  • Synchronous parsing of large JSON responses in click handlers. Move to async + requestIdleCallback or workers.
  • Third-party scripts (chat widgets, analytics, recommendation engines) that run on user interaction. Audit their contribution in Chrome DevTools Performance panel with user tracing enabled.
  • Animation + layout work triggered by clicks. filter, box-shadow, and transform animations with large elements are expensive. Profile and move to transform3d / opacity + will-change where possible.
  • Hydration work in SSR frameworks (Next.js, Nuxt) on initial render. Use progressive hydration, server components, or islands architecture to delay/eliminate unnecessary hydration.

Measuring INP during dev: the web-vitals library exposes the exact interaction that produced your INP, including the target DOM element. Log it. Once you know which interaction fails, the fix becomes tractable.

Fixing CLS: the usual suspects

CLS is often the easiest to fix, because the causes are well-known and the fix is mechanical.

Top causes, in frequency order:

  1. Images without width/height or aspect-ratio. Browser can't reserve space; content reflows when image loads. Fix: <img width="800" height="600"> or CSS aspect-ratio: 800/600.
  2. Ads, embeds, iframes without reserved space. Fix: minimum height on the container, even if the loaded content is smaller.
  3. Web fonts causing FOUT/FOIT. Fallback font has different metrics than custom font; text reflows on font load. Fix: font-display: optional (if you can tolerate FOFT) or matched fallback metrics via size-adjust: 90%; ascent-override: 90%;.
  4. Late-injected DOM (cookie banners, subscribe prompts, chat widgets). Reserve space via fixed-position overlay, or delay injection until user interaction.
  5. Carousel/slider transitions. Most carousel libraries cause CLS on state transitions. Pick a library that uses transform instead of layout changes.

CLS uses session windows (shifts within 1s are grouped, 5s cap). The page's CLS is the worst window. This means one bad widget can blow your CLS score even if the rest of the page is stable. Audit widget-by-widget, not page-wide.

When CWV doesn't matter as much

CWV's ranking weight varies by context. Situations where it's less decisive:

  • Query has few alternatives. If you're the authoritative source for a specific query, ranking signals like E-E-A-T and backlinks overwhelm CWV. Your competitor at position 2 with better CWV won't dislodge you.
  • CrUX has no data for your URL. For low-traffic URLs, CWV defaults to origin-level data or is ignored. The URL ranks on non-CWV signals.
  • Mobile vs desktop split. CWV is evaluated separately per form factor. Passing one and failing the other ranks differently on that form factor's SERPs.

Where CWV is most decisive: competitive commercial queries where multiple sites have comparable content and authority. In those SERPs, the CWV difference can move positions 1-10 meaningfully.

The optimization priority stack

If you have a budget of engineering weeks to spend on performance, here's the ordering that generates the most ranking lift:

  1. Fix any CWV status of "Poor" — these pull down ranking visibly.
  2. Move "Needs Improvement" to "Good" — diminishing returns, but each tier crossing matters.
  3. Don't over-optimize "Good" — going from 2.2s LCP to 1.4s LCP doesn't help rankings; invest elsewhere.
  4. Monitor field data weekly, not lab scores — lab is for debugging, field is for decisions.

Frequently asked questions

Is CWV a major ranking factor?

No. It's real but modest — comparable to the effect of HTTPS (a small, consistent signal). A good CWV score won't rank a thin page; a poor score won't tank an authoritative one. In competitive queries, it can move positions; in non-competitive queries, it rarely does.

Why is my Lighthouse score 100 but CWV failing?

Lighthouse is synthetic — a simulated connection, one run. Real users are on slower devices and networks than Lighthouse's simulation assumes. The Lighthouse score and field CWV score are measuring different things. Trust the field data for ranking decisions.

How do I optimize INP on an SPA without rewriting everything?

Three quick wins before a rewrite: (1) virtualize any list over 50 items. (2) Move third-party scripts behind user-interaction triggers. (3) Profile interactions in Chrome DevTools and identify the single worst long task; break it into smaller async chunks. These often move INP from "Poor" to "Good" without framework changes.

What's the difference between INP and FID?

FID measured only the first interaction's input delay. INP measures the worst interaction's total duration (input delay + processing + paint) across the entire page visit. INP is strictly harder to pass and more reflective of real user frustration.

How long until CWV fixes show up in rankings?

The CrUX rolling window is 28 days. Ship fixes on day 0, CrUX starts reflecting improvement gradually over days 1-28, reaches stable new baseline around day 35-45. Ranking impact follows the CrUX data, typically with a 1-2 week additional lag. Plan for 6-8 weeks end-to-end.

Related articles

a computer screen with a rocket on top of it
Technical SEO

The Complete Guide to Technical SEO Audits

Most technical SEO audits fail the same way: they generate 80-page PDFs with 200 findings, and clients execute none of them. The audits that move rankings solve for one thing: which of five layers is broken, and which single fix restores the most value.

· 11 min read