SEO

Core Web Vitals in 2026: How to Pass on Mobile (Without a Rewrite)

APR 25, 2026 · 10 MIN

Core Web Vitals (CWV) is Google's grading of how fast and stable your page feels to a real user. As of 2026, three metrics matter: LCP, INP, and CLS. CWV scores feed into Page Experience signals, which influence rankings — particularly on mobile, where most users are.

The good news: passing CWV does not require a rewrite. The bad news: most sites fail because of 4–5 specific issues that compound. Here is what each metric measures and the specific fixes.

LCP — Largest Contentful Paint

Measures: how long until the largest above-the-fold element renders. Target: ≤ 2.5s on mobile.

Why yours is bad

  • LCP candidate is a 1MB+ hero image (most common).
  • Hero is a video, animation, or 3D canvas that blocks paint.
  • Web fonts loaded synchronously, causing FOIT or late text paint.
  • Critical CSS not inlined; first paint waits for the full stylesheet.
  • Server response time (TTFB) > 800ms.

Fixes

  • Convert hero images to AVIF or WebP. Serve responsive sizes via srcset.
  • For 3D / animation heroes, render a static fallback (CSS gradient or low-res image) and load the heavy component after first paint.
  • Use font-display: swap and preload the specific weights used above the fold.
  • Inline critical CSS. Defer the rest.
  • Cache static HTML on CDN edge (Vercel, Cloudflare) — cuts TTFB from 500ms to ~50ms.

INP — Interaction to Next Paint

Measures: how long after a user interaction (click, tap, key press) before the next visual update. Target: ≤ 200ms.

Why yours is bad

  • Long-running JavaScript on the main thread (often React hydration).
  • Large chunks of JS loading on click — e.g. modal libraries, charts, rich text editors.
  • Inefficient event handlers that trigger expensive renders.
  • Synchronous third-party scripts (analytics, ads) blocking the thread.

Fixes

  • Code-split aggressively — dynamic import everything not needed for first interaction.
  • Defer third-party scripts. GA4, Meta Pixel, etc. should load after first paint.
  • Use React.startTransition for state updates that trigger heavy re-renders.
  • Profile with Chrome DevTools Performance panel — INP issues show up as long tasks > 50ms.

CLS — Cumulative Layout Shift

Measures: how much layout jumps as the page loads. Target: ≤ 0.1.

Why yours is bad

  • Images without explicit width/height attributes.
  • Web fonts swapping at different sizes than the fallback.
  • Embeds (YouTube, Twitter) loading into containers without reserved space.
  • Banner ads, cookie consent dialogs, or top bars injecting content above the fold.

Fixes

  • Always set width and height on images, or use CSS aspect-ratio.
  • Use size-adjust on @font-face to match fallback metrics to web font metrics.
  • Reserve space for embeds via fixed-aspect-ratio containers.
  • Render banners and consent dialogs in a way that does not push content (overlay, not stack).

Lighthouse vs CrUX — what Google actually scores

Lighthouse runs in your browser on your machine — synthetic, single-run. CrUX (Chrome User Experience report) is the field data Google actually uses for ranking signals: real users, real devices, 28-day rolling window.

They often disagree. Your Lighthouse can be 95 while CrUX shows you failing — because your Lighthouse runs on a fast laptop while real users are on 3-year-old Android phones. Always check CrUX (PageSpeed Insights bottom panel) before declaring victory.

How we approach this

For our SEO Optimization clients, CWV work is one of the highest-ROI engagements we do. Most sites can move from yellow to green on all three metrics in 2–4 weeks of focused work. The fixes are well-known; what is missing is usually engineering capacity and a willingness to challenge "we always loaded fonts this way" assumptions.