A visitor on a phone taps your result and watches a blank screen think about it. The headline appears, they reach for the "Book now" button, and the button jumps an inch as a cookie banner loads above it. They tap the wrong thing and leave. Core Web Vitals are Google's three measurements of that exact experience, taken from real visitors, and they're the one part of technical SEO where Google has published the pass marks.
Three numbers, each measuring one moment
Largest Contentful Paint, LCP, is how long the biggest thing in the first screen, usually a hero image or the main heading, takes to become visible: the closest thing to "how long until the page looks loaded".
Interaction to Next Paint, INP, is how long the page takes to respond visibly after a tap, click or key press, measured across the whole visit and reported as close to the slowest one. A slow INP is the button that does nothing for a moment, then does it twice.
Cumulative Layout Shift, CLS, is how much the content moves around unexpectedly while the page loads. It's a score rather than a time; the jumping button in the opening scene is a layout shift.
The pass marks come from web.dev's Core Web Vitals thresholds: LCP is good at 2.5 seconds or under and poor above 4 seconds; INP is good at 200 milliseconds or under and poor above 500 milliseconds; CLS is good at 0.1 or under and poor above 0.25. Between the two lines a page "needs improvement". Each is judged at the 75th percentile of page loads, per web.dev, so three quarters of your visitors have to get the good experience for the page to pass.
You'll still meet First Input Delay, FID, in older articles and tools; web.dev records that it was retired and replaced by INP in 2024, so anything still scoring FID is out of date.
Field data is the verdict, lab data is the diagnosis
The numbers Google acts on come from real Chrome users who opted in to sharing them, collected in what Google calls the Chrome User Experience Report, or CrUX. Search Console's Core Web Vitals report groups your URLs by that data and labels them good, needs improvement or poor; Google's PageSpeed Insights shows field and lab data for one URL side by side.
A lab test, including the free Website speed test, loads a page once, from one place, on one connection, and reports what it saw: how long until content appeared and until the page settled. That's the tool for finding the cause and checking a fix; the verdict comes from your actual visitors on their actual phones.
Two consequences follow. Pages with little traffic have no field data, so Google can't assess them. And because Search Console groups similar URLs, fixing the product page template moves every product page at once, while fixing one blog post moves one.
What the metrics do to rankings
Google's page experience documentation says Core Web Vitals are used by its ranking systems. The same documentation says Google still ranks the page with the best information first, even when its page experience is weaker. In practice that makes the metrics a tie-breaker between pages that answer the search equally well, and a weak lever for a page that doesn't answer it at all. What actually moves rankings puts this in proportion.
The bigger reason to fix them is the visitor. A page that loads slowly and jumps around converts worse wherever it ranks, so speed work pays for itself on the traffic you already have: a revenue fix that also tidies up a ranking signal.
The fixes that usually matter
Most failures trace back to a handful of causes, and the metric tells you which family to look in.
For LCP, the usual suspect is the hero image: too large, served in an old format, or lazy-loaded so the browser waits for it on purpose. Behind that sit a slow server response (cheap hosting, no caching, no CDN) and scripts and stylesheets that load before the content and block it.
For INP, the cause is almost always JavaScript doing too much while the visitor is trying to interact. Third-party tags are the worst offenders: chat widgets, A/B testing tools, heatmaps, and the tag manager that loads them all. Remove the tags nobody uses, delay the rest, and ask the developer to break up the long-running scripts that remain.
For CLS, something is being added to the page without space reserved for it: images and embeds without width and height attributes, banners injected above the content, ads that load late, and a web font that swaps in at a different size. Give every late arrival its space in advance, and put notices in a slot that already exists.
Nearly all of this is developer or theme work. Your job is to measure, name the page and the metric, and point at the element responsible.
What to take away
- Core Web Vitals are three measurements of real visitors' experience: LCP for loading, INP for responsiveness and CLS for visual stability, with pass marks published by web.dev.
- The verdict comes from field data at the 75th percentile of visits, so lab tests like a speed test are for diagnosis and checking a fix, not for the score.
- Google's page experience documentation says the metrics feed into ranking and that content relevance comes first, so treat them as a tie-breaker and a conversion lever.
- Most failures come from an oversized hero image, too much JavaScript running during interaction, or page elements arriving without reserved space.
Next
The plumbing is sound; now put something worth ranking through it, in Writing a page that ranks.