What Is Core Web Vitals?

How Core Web Vitals Work

Core Web Vitals answer a deceptively simple question: does this page feel good to use? Google splits that feeling into three measurable dimensions and sets a pass mark for each. Largest Contentful Paint captures loading — how long until the biggest piece of visible content appears. Interaction to Next Paint captures responsiveness — how quickly the page reacts when you tap, click, or type. Cumulative Layout Shift captures visual stability — whether content jumps around while the page settles.

Each metric has a three-band scale: good, needs improvement, and poor. The good thresholds are the ones worth memorizing: LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1. A page “passes” Core Web Vitals only when all three metrics with sufficient data are in the good band.

The measurement detail that trips people up is the 75th percentile. Google does not average your visits; it takes the value that 75% of page loads come in under, segmented across mobile and desktop. That choice is deliberate — it means a page passes only when the large majority of real users get a good experience, so a fast median can’t paper over a slow tail. The data comes from the Chrome UX Report, which aggregates anonymized measurements from real Chrome users over a rolling 28-day window.

The Three Metrics

• Largest Contentful Paint (LCP) — loading. Reports the render time of the largest image, text block, or video in the viewport, relative to when navigation started. Good is ≤ 2.5s; poor is > 4.0s.
• Interaction to Next Paint (INP) — responsiveness. Observes the latency of every click, tap, and keypress across the whole visit and reports the slowest. Good is ≤ 200ms; poor is > 500ms. It replaced First Input Delay in 2024.
• Cumulative Layout Shift (CLS) — visual stability. Sums the largest burst of unexpected layout movement into a unitless score. Good is ≤ 0.1; poor is > 0.25.

Note what is not here: raw page speed numbers like total load time or page weight. Core Web Vitals are experience metrics, not stopwatch readings. A heavy page can pass all three if it prioritizes visible content, and a light page can fail if its layout jumps or its JavaScript blocks the main thread.

Example of Core Web Vitals

The clearest documented moment in the metric set’s history is the March 12, 2024 swap of INP for FID — the first time Google replaced a Core Web Vital. The change is worth walking through because it shows how the standard actually evolves.

Google first shipped Core Web Vitals in 2020 with LCP, FID, and CLS. First Input Delay measured only the delay before the browser could begin processing the very first interaction — a narrow slice that most real pages passed easily, which made it a weak signal. Chrome introduced INP as an experimental metric in May 2022, announced in May 2023 that it would become a Core Web Vital, and formally promoted it on March 12, 2024. First Input Delay was then deprecated across Chrome’s tools and APIs on September 9, 2024.

The substitution changed what “responsive” means in practice. INP measures the full latency — input delay, event processing, and rendering — of all interactions during a visit, not just the first, and reports the worst one. Because its good threshold is 200 milliseconds and it captures the whole session, sites that comfortably passed FID often found themselves in the needs-improvement or poor band overnight, exposing sluggish handlers and heavy JavaScript that FID never surfaced.

The lesson generalizes: Core Web Vitals are a moving target maintained by Chrome’s engineering team, and each metric is chosen to reflect real friction rather than to be easy to pass. When a metric stops discriminating between good and bad experiences, Google replaces it. Optimizing for the current three is worthwhile, but the durable strategy is building genuinely fast, stable, responsive pages — the property the metrics are only ever a proxy for.

Where Core Web Vitals Fit

Core Web Vitals sit inside Google’s wider page experience signals, alongside HTTPS and mobile-friendliness. Google has been consistent that they are a lightweight ranking input — a way to prefer the better experience when two pages are otherwise comparable, not a lever that outranks relevance. Chasing green scores on a page that doesn’t match search intent is effort spent in the wrong place. The right sequence is content and relevance first, then vitals as the polish that helps you edge out equally-relevant competitors and, just as importantly, keeps real users from bouncing off a slow or jittery page.

Frequently Asked Questions

The Bottom Line

Core Web Vitals distill “does this page feel fast and stable to a real person” into three measurable numbers with published pass marks. They reward pages that render their main content quickly, react to taps without lag, and hold their layout still while loading. Treat them as a health check on real-user experience, verified in the field rather than the lab.