"Make the site faster" used to be reasonably vague advice, measured against a single overall score. Core Web Vitals broke that vague goal into a small set of specific, measurable metrics tied to real aspects of user experience — which makes performance work far more actionable, once you know what each one actually measures.
The Three Core Metrics
Largest Contentful Paint (LCP) measures how long it takes for the largest visible element on the page — usually a hero image or headline block — to fully render. This approximates when the page feels like it's actually "loaded" to a real visitor. A good target is under 2.5 seconds.
Interaction to Next Paint (INP) measures how responsive the page feels when a visitor actually interacts with it — clicking a button, opening a menu — and how long it takes the page to visibly respond. A good target is under 200 milliseconds. A page that loads quickly but feels sluggish to interact with fails this metric even with a fast LCP.
Cumulative Layout Shift (CLS) measures visual stability — how much content unexpectedly shifts position while the page is loading, like a button moving right as you're about to tap it because an ad loaded above it. A good target is under 0.1.
Why These Specific Metrics
Each one maps to a genuine, common source of user frustration: a slow-loading page, a page that feels unresponsive despite loading fast, and a page that shifts unpredictably underneath a visitor trying to interact with it. Because they're specific and measurable, they turn "make the site feel faster" into concrete, prioritizable engineering work rather than a vague aspiration.
A Simple Framework
- Measure current Core Web Vitals scores using real, field data where possible, not just lab tests — real user conditions vary more than a single test run captures
- Identify the specific metric performing worst and address its most common causes: LCP issues often trace to unoptimized images or slow server response; CLS issues often trace to content (ads, embeds, fonts) loading without reserved space; INP issues often trace to heavy JavaScript blocking the main thread
- Fix the most impactful issue first rather than spreading effort thin across many small optimizations
- Re-measure after each change using both lab and field data to confirm real improvement
> Tip: Reserve space for images, ads, and embeds before they load, using explicit dimensions, rather than letting the page layout shift once they arrive. This single fix often resolves the majority of a site's CLS problems.
Common Mistakes
- Optimizing only against lab test scores, which don't always reflect real-world user conditions
- Fixing whichever metric is easiest rather than whichever is actually worst
- Ignoring INP specifically because it's newer and less familiar than the older, longer-standing metrics
- Treating Core Web Vitals as a one-time project instead of an ongoing check, since new page elements can reintroduce old problems
For live, authoritative benchmarks and testing, Google's PageSpeed Insights reports Core Web Vitals directly against both lab and real-world field data.
Page speed stopped being a vague, single-number concern once it was broken into these three measurable pieces — which makes the work more precise, but also means there's no longer an excuse to guess at what "faster" actually requires.