Core Web Vitals, Explained in Plain English

Core Web Vitals get referenced constantly in SEO advice, usually as a vague instruction to "improve your score." But they're not vague at all — they're three specific, precisely defined metrics, each measuring a different kind of frustration a real visitor experiences on a page. This guide explains exactly what each one measures, the specific thresholds Google uses to grade them, and the mechanics behind how those grades get calculated. For the practical fixes once you understand what's being measured, see the website speed and SEO guide.

The three metrics, one at a time

LCP — Largest Contentful Paint: "does this feel loaded?"

LCP measures the time from when a page starts loading until the largest visible element in the viewport — usually a hero image, a large block of text, or a banner — has fully rendered. It's a proxy for the moment a visitor would say the page "looks loaded," even if smaller elements are still arriving.

• Good: 2.5 seconds or less.
• Needs improvement: between 2.5 and 4 seconds.
• Poor: more than 4 seconds.

The most common cause of a poor LCP is a slow server response holding up the entire page, or a large, unoptimized image being the "largest element" and taking too long to download and decode.

INP — Interaction to Next Paint: "does this feel responsive?"

INP measures the delay between a visitor's interaction — a tap, a click, a key press — and the moment the browser visibly updates the screen in response. Unlike its predecessor metric (First Input Delay), which only looked at the very first interaction on a page, INP is calculated across every interaction during the full visit, using roughly the worst (slowest) one as the representative score.

• Good: 200 milliseconds or less.
• Needs improvement: between 200 and 500 milliseconds.
• Poor: more than 500 milliseconds.

Poor INP is almost always a JavaScript problem — heavy scripts tying up the browser's main thread so it can't process the interaction and repaint the screen quickly. Third-party scripts (chat widgets, booking calendars, ad tags, tracking pixels) are frequent culprits, since they execute code you don't directly control on every page they're loaded on.

CLS — Cumulative Layout Shift: "does this feel stable?"

CLS measures unexpected movement of visible content during the page's lifespan — not movement caused by a visitor's own action (like opening a menu), but content that shifts because something else finished loading and pushed it around. It's scored, not timed: a unitless number representing how much content moved and how large that content was, summed across the whole visit.

• Good: 0.1 or less.
• Needs improvement: between 0.1 and 0.25.
• Poor: more than 0.25.

The textbook cause is an image or ad slot without a reserved size, which collapses to zero height until it loads, then shoves everything below it downward. Web fonts that load late and swap in with different dimensions than a fallback font cause a related, smaller-scale version of the same problem.

Lab data vs. field data: two different measurements, one confusing name

A lot of confusion around Core Web Vitals comes from not distinguishing these two data sources, which can disagree with each other for entirely legitimate reasons.

Lab data is generated by running a controlled, simulated test at a specific moment — this is what tools like Lighthouse or a fresh PageSpeed Insights run produce. It's useful for debugging because it's reproducible and immediate, but it reflects one specific set of conditions, not your real audience.

Field data is collected from real Chrome users who actually visited your page, aggregated over a rolling 28-day window through the Chrome User Experience Report (CrUX). This is the data source behind the Core Web Vitals report in Google Search Console, and it's the number that reflects — and factors into — actual page experience at scale.

The 75th percentile rule

Google doesn't grade a page on its average performance — it uses the 75th percentile of page loads (or visits) as the representative number for each metric. That means for a page to be classified as "good" for LCP, at least 75% of the recorded visits to that page need to hit an LCP of 2.5 seconds or less. A handful of very fast loads don't offset a long tail of slow ones; the threshold has to hold for the large majority of real visits, not just the best-case scenario.

Where to actually check your numbers

The Core Web Vitals report inside Google Search Console is the most useful starting point because it groups your URLs by issue and uses field data by default — far more actionable than testing pages one at a time. PageSpeed Insights shows both lab and (when available) field data for a single URL side by side, which is useful once you're diagnosing a specific page rather than scanning the whole site.