What they are

Core Web Vitals are a small set of user-centric performance metrics Google defines to capture how a page feels to load and use - and, since 2021, uses as a ranking signal. SEO basics compressed all of this into "fast and mobile-friendly." This is that sentence expanded into the three numbers that actually get measured.

The set is deliberately small and occasionally changes as the web platform improves the tooling. Today it is three metrics, each standing in for one dimension of experience:

  • LCP - Largest Contentful Paint - loading: how quickly the main content appears.
  • INP - Interaction to Next Paint - responsiveness: how quickly the page reacts to input.
  • CLS - Cumulative Layout Shift - visual stability: how much the layout jumps around.

Each has three bands - good, needs improvement, and poor - and the target is to sit in "good" for the 75th percentile of real visits. That percentile detail matters more than it looks; section 05 is where it bites.

LCP: loading

Largest Contentful Paint measures the time from navigation start until the largest content element in the viewport - usually a hero image, a video poster, or a big block of text - finishes rendering. It is a proxy for "when does the page look loaded to the user." Good is ≤ 2.5s; poor is beyond 4s.

What pushes LCP into the red is rarely one thing. The usual suspects: a slow server response (high TTFB), render-blocking CSS and JavaScript in the <head>, and the LCP element itself being a large, unoptimized, or lazy-loaded image. The fixes track the causes - fast server or CDN, inline critical CSS and defer the rest, and never lazy-load the hero. Preloading the LCP image is often the single highest-leverage change.

INP: responsiveness

Interaction to Next Paint measures how quickly the page paints a visual response after a user interacts - a tap, click, or key press. It observes all interactions across the visit and reports (near) the worst, so a single janky interaction can sink the score. Good is ≤ 200ms. INP replaced First Input Delay (FID) in March 2024 - FID only measured the delay before processing began; INP measures the whole interaction through to the next paint, which is what a user actually perceives.

The root cause is almost always the main thread being blocked by long JavaScript tasks - heavy event handlers, large re-renders, third-party scripts. The remedies are the classic responsiveness toolkit: break long tasks up, yield to the main thread, defer non-critical work, and cut the amount of JavaScript that runs on interaction in the first place.

CLS: visual stability

Cumulative Layout Shift is the odd one out - not a time but a unitless score of how much visible content shifts position unexpectedly while the page loads. You have felt it: you go to tap a button and an image loads above it, shoving everything down. Good is ≤ 0.1; poor is above 0.25.

The causes are specific and fixable: images and video without width and height attributes (so the browser cannot reserve space), ads or embeds injected without a placeholder, and web fonts that reflow text when they swap in. The fixes mirror them exactly - always set dimensions on media, reserve space for anything injected, and manage font loading so late-arriving fonts do not reflow the page.

Lab data vs field data

This is the distinction that trips up teams optimizing Core Web Vitals, and the reason a perfect Lighthouse score does not guarantee a passing grade:

  • Lab data is synthetic - a tool like Lighthouse loads the page in a controlled environment on simulated hardware and network. Reproducible, great for debugging, available on demand.
  • Field data is real - collected from actual Chrome users via the Chrome User Experience Report (CrUX), aggregated over a trailing 28-day window at the 75th percentile.

Search ranking uses field data, not lab data. So your slow real users - on mid-range phones and flaky networks - are what count, not your dev machine on fibre. A page can score 100 in Lighthouse and still fail Core Web Vitals in the field because a third of real visits are slow. Optimize for the field distribution, and treat lab tools as the debugger, not the scoreboard.

How much it weighs

The honest, intermediate answer: less than the effort often spent on it, and more than zero. Core Web Vitals are part of Google's page experience signals - a real but relatively lightweight input to ranking, well below relevance, content quality, and links. Google has been explicit that great page experience does not rescue thin or irrelevant content, and that it functions mostly as a tiebreaker between pages that are otherwise close.

So the tradeoff to name: chasing a perfect 100/100/100 at the cost of shipping the content people actually searched for is backwards. The right target is "good" in the field for your real users - which also happens to be the point of diminishing returns for ranking. Past that, you are optimizing for the reader's experience, which is a fine reason on its own, just not a ranking one.

Measuring and fixing

The tools split along the lab/field line from section 05:

  • PageSpeed Insights - shows both: field data from CrUX (if the page has enough traffic) alongside a Lighthouse lab run.
  • Search Console's Core Web Vitals report - the production view, grouping URLs by status from real field data across the whole site.
  • The web-vitals library - measures the real metrics in your own analytics, straight from the browser API that field data is built on:
import { onLCP, onINP, onCLS } from 'web-vitals';

// report each metric to your analytics as it's finalized
function send(metric) {
  navigator.sendBeacon('/analytics', JSON.stringify(metric));
}

onLCP(send);   // loading
onINP(send);   // responsiveness
onCLS(send);   // visual stability

The loop mirrors the Search Console pattern from the rest of the series: measure the field, find the pages in "needs improvement" or "poor," fix the specific cause per metric, and watch the 28-day field data catch up. It is slower than a lab score - real-user data lags - but it is the number that ranking actually reads.

References