Core Web Vitals, Explained Without the Jargon
Three metrics, three plain-language questions: does it appear quickly, does it respond when tapped, and does it stay still? Here is what each measures and what actually fixes it.
Core Web Vitals are three metrics Google uses to measure page experience. LCP measures how quickly the main content appears and should be under 2.5 seconds. INP measures how quickly the page responds to taps and should be under 200 milliseconds. CLS measures unexpected layout movement and should be under 0.1.
What They Actually Measure
Each metric corresponds to a question a real visitor asks without thinking about it. Stripped of the acronyms, the set is easy to reason about — and easier to prioritise, because each has distinct causes and distinct fixes.
Largest Contentful Paint asks: how long until the main thing appears? Not the first pixel, but the element that makes the page feel loaded — usually the hero image or the headline. Google's threshold is 2.5 seconds, and it should be measured on a mid-range phone on a mobile connection rather than on the machine the site was built on.
Interaction to Next Paint asks: when someone taps, how long before something visibly happens? It replaced the older First Input Delay metric, and it is stricter in a useful way — it measures every interaction across the visit rather than only the first, and it measures until the screen updates rather than until processing begins. The threshold is 200 milliseconds.
Cumulative Layout Shift asks: does the page hold still? It is the metric behind the universal experience of reaching for a button and having an advert push it out from under your thumb. Scored from zero, with under 0.1 considered good.
The Thresholds
Google publishes three bands per metric. The bar to clear is the 75th percentile of real visits — meaning three quarters of your actual visitors must be in the good band, so a fast experience for most people is not sufficient if the tail is bad.
| Good | Needs work | Poor | |
|---|---|---|---|
| LCP — main content appears | Under 2.5s | 2.5s – 4.0s | Over 4.0s |
| INP — response to interaction | Under 200ms | 200ms – 500ms | Over 500ms |
| CLS — layout stability | Under 0.1 | 0.1 – 0.25 | Over 0.25 |
Why Your Score Disagrees With Itself
PageSpeed Insights shows two sets of numbers that routinely contradict each other. Understanding which one Google actually uses saves a great deal of wasted optimisation effort chasing a score that was never the target.
Lab data is a single simulated load under fixed conditions. It is repeatable, which makes it excellent for diagnosis — you can change something and immediately see whether it helped. It is not what Google ranks on.
Field data comes from the Chrome User Experience Report: real measurements from real Chrome users on real devices and connections, aggregated over 28 days. This is what feeds the page experience signal. It is also why fixes appear to do nothing for weeks — you are watching a month-long rolling average absorb a change made yesterday.
The practical approach is to use lab data to find and verify fixes, and field data to judge whether the site is actually acceptable. A site can score poorly in the lab and pass in the field if its real visitors are on good devices, and vice versa. Chasing a perfect lab score past that point is optimisation for its own sake.
Fixing LCP
LCP problems almost always come down to the largest element being discovered late, delivered slowly, or blocked by something else. In rough order of how much they typically recover:
Serve the hero image properly
Correctly sized for the viewport, in a modern format, and never lazy-loaded — lazy-loading the element that defines LCP delays the exact thing being measured. Give it explicit priority so the browser fetches it early rather than discovering it during layout.
Remove render-blocking resources
Stylesheets and synchronous scripts in the head stop rendering until they finish. Inline what is needed for the first screen and defer the rest. Third-party scripts are the usual offenders and the easiest to defer.
Fix slow server response
If the server takes 800ms to send the first byte, no front-end work will reach 2.5 seconds reliably. Pre-render pages where the content allows it and put a CDN in front of them — static pages served from an edge cache remove this problem outright rather than reducing it.
Preload the fonts that appear in the first screen
Text held invisible while a font downloads delays LCP when that text is the largest element. Preload the specific face, and set a display strategy that shows fallback text immediately rather than waiting.
Fixing INP and CLS
These two are usually cheaper to fix than LCP, and CLS in particular is often a handful of lines away from resolved.
INP — break up long JavaScript tasks
A single task occupying the main thread for 300ms means any tap during it waits. Split heavy work into smaller pieces and yield between them so the browser can respond. Analytics, chat widgets and consent banners are frequent causes.
INP — do less on the main thread at load
Hydrating an entire page of interactive components when only a few need interactivity is a common self-inflicted cost. Ship interactivity only where it is actually used.
CLS — reserve space for every image and embed
Explicit width and height attributes, or a CSS aspect ratio, let the browser hold the space before the asset arrives. This is the single highest-yield CLS fix and it is nearly free.
CLS — never insert content above existing content
Banners, notification bars and late-loading adverts that push the page down are the classic cause. Reserve their space in the initial layout, or overlay them rather than inserting them into the flow.
Common Questions
What people ask once the numbers stop being abstract.
How much do Core Web Vitals affect rankings?
They are a real but modest signal, and they are a tiebreaker rather than a lever. A fast page with weak content will not outrank a slow page that answers the query better. Where speed pays reliably is conversion — bounce rate rises sharply with load time regardless of what ranking effect exists.
Why did my score drop without any changes?
Field data reflects your actual visitors, so a shift in traffic mix moves the numbers. More mobile visitors, more visitors on slower connections, or a new region can all lower scores with no change to the site. Third-party scripts also change independently of you.
Is a perfect 100 worth chasing?
Rarely. The gap from poor to good is where the value is; the gap from good to perfect usually costs more than it returns and often means stripping functionality that earns its keep. Clear the thresholds, then spend the effort elsewhere.
How long until improvements show up?
Lab data updates immediately. Field data is a 28-day rolling average, so a fix deployed today is fully reflected roughly a month later, with partial movement before that. Do not judge a change after a week.