Scanverra
Back to Articles
Performance

Core Web Vitals in 2026: A Practical Guide to Faster Websites

·9 min read

Most teams find out they're failing Core Web Vitals from a drop in Search Console, not from watching the page load. That's backwards. Here's what the three metrics actually measure, why Google cares, and a prioritized list of what to fix first.

What Are Core Web Vitals?

Core Web Vitals are three metrics Google uses to approximate how fast and stable a page feels to a real visitor, not just how fast it loads in isolation:

  • LCP (Largest Contentful Paint) - how long until the biggest visible element (usually a hero image or heading) has rendered.
  • INP (Interaction to Next Paint) - how long the page takes to visually respond after a click, tap, or keypress.
  • CLS (Cumulative Layout Shift) - how much content jumps around while the page is loading.

Since 2021 these have been a confirmed Google ranking factor, and since March 2024, INP replaced First Input Delay (FID) as the official responsiveness metric. If your audit tooling still only talks about FID, it's measuring the wrong thing.

Largest Contentful Paint (LCP)

Target:2.5 seconds or less. Above 4 seconds is classified "poor."

The usual causes, roughly in order of how often we see them:

  • Render-blocking CSS or JS in the <head> that delays first paint entirely.
  • An unoptimized hero image - full-resolution JPEGs/PNGs served at display size instead of a compressed, responsive format.
  • Slow Time to First Byte (TTFB) from the origin server or a cold serverless function.
  • Web fonts blocking text render instead of falling back immediately.

Fixes that move the needle fastest:

  • Serve images through something like next/image - automatic format negotiation (AVIF/WebP), resizing, and lazy-loading everything below the fold.
  • <link rel="preload"> the actual LCP image or font instead of letting the browser discover it late.
  • Move non-critical JS out of the initial render path (dynamic imports, defer).
  • Put static pages and assets behind a CDN so TTFB isn't round-tripping to a single origin region.

Interaction to Next Paint (INP)

Target:200ms or less. Above 500ms is "poor."

INP is measured across every interaction on the page, then reports something close to the worst one - so a single janky click handler can tank your score even if everything else is smooth. Common culprits: long JavaScript tasks blocking the main thread, heavy third-party scripts (analytics, chat widgets, ad tags) competing for the same thread, and large state updates re-rendering more of the page than necessary.

Fixes:

  • Break up long tasks - anything over 50ms blocking the main thread is a candidate for splitting or deferring.
  • Code-split so route-specific JS doesn't load (and execute) on pages that don't need it.
  • Move genuinely expensive work (parsing, heavy computation) off the main thread with a web worker.
  • Audit third-party scripts - a surprising amount of INP damage comes from tags marketing added and nobody ever removed.

Cumulative Layout Shift (CLS)

Target:0.1 or less. Above 0.25 is "poor."

Almost every CLS problem traces back to one of three things:

  • Images or embeds rendered without explicit width/height, so the browser doesn't reserve space before they load.
  • Content injected above existing content - cookie banners, ads, or promo bars that push everything down after the initial paint.
  • Web fonts swapping in and reflowing text (FOIT/FOUT) without a reserved layout box.

The fix is almost always the same: reserve the space up front. Set explicit dimensions on every image and iframe, use font-display: swap with a size-matched fallback font, and if something has to be injected dynamically, give it a fixed-height container from the start instead of letting it push content around.

Field Data vs. Lab Data

Two different measurement worlds get conflated constantly:

  • Field data (CrUX, Search Console) - real measurements from real visitors' browsers over the last 28 days. This is what actually affects ranking.
  • Lab data (Lighthouse, PageSpeed Insights) - a simulated run on a single synthetic device/connection. Useful for debugging, not what Google ranks on.

A page can score 100 in Lighthouse and still fail field CWV if your real traffic skews toward older phones on slower connections. Treat lab scores as a debugging tool, not the scoreboard.

A 10-Minute Action Plan

  • Run a real audit and note which of the three metrics is actually failing - don't guess.
  • If it's LCP: check your hero image is compressed and preloaded.
  • If it's INP: check for one dominant long task, usually a third-party script.
  • If it's CLS: check every image and embed has explicit dimensions.
  • Re-scan after each fix - these three metrics interact less than people assume, so fix them one at a time.

See your Core Web Vitals right now

Run a free instant audit and get an AI-prioritized fix list for LCP, INP, and CLS.

Run a free audit