Core Web Vitals are three measurements Google uses to describe how a page feels to use, and one of the few ranking signals the company documents openly with published numbers you can check yourself.
They are not a score to chase. Each one asks a specific question about a specific moment in the page's life, and the fixes have almost nothing in common.
The three metrics
Largest Contentful Paint — how long until it looks loaded
LCP measures when the largest element in the viewport finishes rendering. Usually that is a hero image, a video poster, or the main heading.
- Good: 2.5 seconds or less
- Needs improvement: up to 4 seconds
- Poor: over 4 seconds
This is the metric that maps most closely to what people mean by "the site is slow". Someone waiting for a page is waiting for the main thing on it to appear, and LCP is that moment.
The frequent misunderstanding is that LCP is about image size. Image weight is one cause of four, and often not the largest one — see how to improve Largest Contentful Paint for finding out which cause is yours.
Interaction to Next Paint — how long until it responds
INP measures the delay between a user interacting — tap, click, key press — and the page visibly updating. It samples the worst interactions across the whole visit, not just the first.
- Good: 200 ms or less
- Needs improvement: up to 500 ms
- Poor: over 500 ms
INP replaced First Input Delay as a Core Web Vital in March 2024, and the change made the metric considerably harder to pass. FID only measured the delay before the browser started processing the first interaction. INP measures every interaction and includes the time to actually paint the result — which is where slow JavaScript really shows up.
If you last looked at Core Web Vitals before 2024 and were passing, it is worth re-checking.
Cumulative Layout Shift — how much it moves around
CLS measures how much visible content jumps position while loading, as a unitless score combining how much moved and how far.
- Good: 0.1 or less
- Needs improvement: up to 0.25
- Poor: over 0.25
CLS is the one users can describe without knowing the term: the page where you go to tap a link and an ad loads above it, so you tap the ad instead.
The distinction that matters more than the metrics
Every Core Web Vital exists in two versions, and confusing them wastes an enormous amount of effort.
Lab data is a simulation. A tool like Lighthouse loads your page once, on a throttled connection, on a simulated mid-range phone, in a data centre. It is repeatable, available for any URL, and useful for diagnosis because you can change something and immediately see whether it helped.
Field data is what real Chrome users experienced, at the 75th percentile, over the previous 28 days. It comes from the Chrome User Experience Report, and it covers real devices on real networks in real places.
Google ranks on field data. The lab score is a diagnostic tool, not the thing being measured.
This is why lab and field routinely disagree, and why that disagreement is not a bug:
- A change you shipped this morning shows in the lab instantly and takes weeks to move the field data, because the field number is a 28-day rolling window.
- Your audience may be on faster devices than the simulated mid-range phone, so the field data is better than the lab.
- Or they may be on far worse connections in places with higher latency, so it is worse.
- CLS in particular is often much higher in the field, because real users scroll and interact in ways a lab run does not — and shifts triggered by scrolling still count.
The Website Speed Test shows both, labelled separately, and says plainly when field data is unavailable.
"No field data available" is normal
Most sites have no field data at all. CrUX only reports where there is enough Chrome traffic to anonymise the data — roughly a few thousand visits a month to a given page.
This is not a fault and there is nothing to fix. It does mean two things worth knowing:
- You are judged on lab data by tools, and on nothing by Google. Without field data there is no Core Web Vitals ranking signal for that page either way.
- Your own field data is the better target. If you want real numbers for a low-traffic site, collecting them from your own visitors with the
web-vitalsJavaScript library gives you data CrUX will never have.
Where a page has too little traffic but the origin has enough, Google may report origin-level data instead — a site-wide average rather than that page. That is flagged in the results, because "this page is fast" and "this site averages fast" are different claims.
Which to fix first
When all three are failing, the order that usually pays off fastest:
Start with LCP if server response time is high. Time to first byte sits underneath everything — the page cannot render before the first byte arrives, so a slow server caps LCP no matter what you do to the images. See what is a good TTFB.
Then CLS, because it is usually the cheapest. Most CLS comes from images and ad slots with no reserved dimensions. Adding width and height attributes is a small change with an immediate, permanent effect, and it cannot regress the other metrics.
Then INP, because it is usually the most work. Improving it means reducing JavaScript, which means auditing third-party scripts and often having an uncomfortable conversation about which marketing tags actually earn their cost.
What Core Web Vitals will not do
Worth being blunt, because plenty of people spend months here for the wrong reasons.
They are a small ranking signal. Google has said so directly. Relevance and content quality dominate. Making a slow page fast will not outrank a page that answers the query better, and no amount of green scores rescues thin content.
A perfect score is not the goal. The thresholds are pass or fail bands, not a gradient — there is no additional ranking benefit to an LCP of 0.9 seconds over 2.4 seconds. Once you are inside the threshold, stop and go do something else.
They measure loading, not usability. A page can pass all three and still be unusable: bad navigation, unreadable contrast, a broken checkout. Core Web Vitals see none of that.
The honest reason to care is behavioural rather than algorithmic. Slow pages lose visitors before anything renders, and jumpy pages lose them at the moment of interaction. That shows up in conversions long before it shows up in rankings — and unlike rankings, it is entirely within your control.
Checking yours
Run a page through the Website Speed Test. It reports lab and field data separately, shows the threshold each value was judged against, and measures server response time independently — the number that determines the ceiling for everything else.