Core Web Vitals measure three fairly specific parts of a website's experience:
- how long it takes for the main content to appear;
- how it responds when someone interacts with it;
- and how much it moves around unexpectedly while it loads.
They're LCP, INP and CLS.
Google recommends achieving good Core Web Vitals and says they're aligned with what its ranking systems aim to reward. But it also makes clear that there's no single page experience signal, and that it tries to show the most relevant content even when the page experience isn't great.
A fast website with content that isn't very relevant still has that problem.
And a score of 100 in Lighthouse shouldn't become the goal of the project either.
The three Core Web Vitals
| Metric | What it tries to measure | Good |
|---|---|---|
| LCP | When the main content appears | ≤ 2.5 s |
| INP | How the page responds to interactions | ≤ 200 ms |
| CLS | How much content moves unexpectedly | ≤ 0.1 |
Google assesses these values at the 75th percentile of visits, separately for mobile and desktop.
That means a website isn't judged on one perfect load from your own computer.
It's about the experience most real users get.
LCP: when the important part appears
Largest Contentful Paint measures when the largest visible element on the first screen is shown: usually an image, a block of text or a video.
If it takes too long, common causes include:
- a heavy or poorly served main image;
- a slow server response;
- fonts, CSS or JavaScript delaying rendering;
- lazy-loading an element that should appear straight away.
It's not about the whole page finishing loading within 2.5 seconds.
LCP measures something much more specific.
INP: how it responds when you do something
Interaction to Next Paint measures how long the page takes to show a visual response after interactions such as clicking, tapping or using the keyboard.
A high INP tends to make a website feel sluggish, even if it seemed to load quickly.
Heavy JavaScript, long tasks and third-party scripts are common causes.
INP replaced FID as a Core Web Vital in 2024.
CLS: so the page doesn't move under your finger
Cumulative Layout Shift measures unexpected movement.
The classic example: you go to tap a button, an image loads, everything shifts down and you end up tapping something else.
Reserving space for images and embeds, controlling how fonts load and avoiding inserting things above existing content all help reduce it.
PageSpeed Insights mixes two kinds of data
This distinction matters more than chasing the big number at the top.
Field data
This is the experience of real users, collected through the Chrome UX Report (CrUX).
When there's enough of it, PageSpeed Insights can show it, and Search Console uses it for its Core Web Vitals report.
It's the most useful data for knowing what's actually happening to the people who visit your website.
A new or low-traffic website may not have enough of it.
That doesn't mean there's a problem.
It means there isn't a large enough sample yet.
Lab data
This is a test run under controlled conditions.
Lighthouse falls into this group.
It's extremely useful for finding problems and testing changes during development, but it doesn't reproduce every device, connection and interaction real users have.
That's why you can have an excellent Lighthouse score and field data that needs work, or the other way round.
Also, in a standard page-load test Lighthouse doesn't measure INP, because nobody interacts with the page during the test. It uses other metrics, such as Total Blocking Time, as a proxy to help spot related problems, though they don't replace it.
What about TTFB?
Time to First Byte measures how long it takes for the server's response to start arriving.
It isn't a Core Web Vital.
It can help diagnose a slow LCP, because everything that happens afterwards depends on the response starting to arrive.
As a guide, web.dev suggests 0.8 seconds or less as a good target for most websites.
But I wouldn't chase that number on its own if the real experience is already good.
How I'd review them
My order would be fairly simple:
- Check first whether there's any field data. Search Console and PageSpeed Insights can tell you whether real users are having a problem.
- Identify which metric is failing. LCP, INP and CLS usually have quite different causes.
- Use lab tools to investigate. DevTools and Lighthouse help you find which image, script or behaviour is causing it.
- Prioritise the pages that really matter. A main landing page, a service page or a shop deserves attention before a leftover URL with no traffic.
- Fix the cause and measure again.
Field data doesn't change immediately after you deploy an improvement.
It needs new visits and time to reflect it.
Don't optimise a website against its own purpose
Some improvements are obvious: a huge image that could be served better, unnecessary JavaScript, a layout that jumps, a badly loaded font.
Make them.
But removing a necessary photo, a useful form or an important feature just to shave off a few tenths may be solving the wrong problem.
Core Web Vitals help you spot experiences that could be better.
Not decide what your business should have on its website.
What matters in the end
I'd aim for good values in all three.
But I wouldn't use Core Web Vitals as an overall quality score for the website, or as an SEO promise.
They're part of something broader: content, structure, usability, accessibility, how it works and the real experience.
If you want to know which problems are worth prioritising before you start changing things, that's what we review in a Website Audit.
And if you work with Next.js and want a broader technical review, there's also our technical SEO checklist for Next.js.
We write about decisions that come up in real projects: how to structure a website, how to capture demand and when technology can simplify a business.