Someone runs your site through PageSpeed Insights, or an SEO tool sends you a monthly email, and suddenly there are three acronyms on the screen in red or amber: LCP, INP and CLS. The report says your site has “failed” something. You did not know it was being tested.
This page is Core Web Vitals explained without the jargon: what each of the three measures, the line Google draws between good and not good, how the data is collected, and where you can see your own numbers. It deliberately stops short of fixes. Each metric has its own post for that, linked as we go.
Core Web Vitals explained in one paragraph
Core Web Vitals are three measurements Google chose to describe how a page feels to a real person using it. Not how much the page weighs, not how many files it loads, but what the visitor actually experiences: how long before the main content appears, how quickly the page reacts when they tap something, and whether things jump around while they are reading. Google publishes the metrics, the thresholds and the tools openly, and uses the same numbers in Search Console.
So what are Core Web Vitals, in a sentence? A visitor’s patience, measured three ways. A useful way to hold them in your head is as three questions a visitor would ask without ever saying them out loud.
- Has it shown up yet? That is Largest Contentful Paint (LCP).
- Did it hear me? That is Interaction to Next Paint (INP).
- Will it keep still? That is Cumulative Layout Shift (CLS).
Largest Contentful Paint: has the main thing appeared?
When a page starts loading, the browser paints things in pieces. A logo, a menu, a block of text, then perhaps a large photo. LCP records the moment the biggest piece of content in the visible part of the screen finished rendering. On most business sites that is a hero image, a banner, or a large heading. On a blog post it is often the featured image or the first paragraph.
The reason Google picked the largest element is simple: that is roughly when a visitor decides the page has “loaded”. A spinner and a menu bar do not count as arriving. The big picture of your product does.
Google’s line: LCP is good at 2.5 seconds or less. Slow LCP usually traces back to a slow server, a heavy or late-discovered hero image, or CSS and fonts holding the page back. Our post on finding and fixing a slow LCP element goes through those in order.
Interaction to Next Paint: did the page respond?
INP is about what happens after the page has loaded. A visitor taps “Add to cart”, opens the mobile menu, ticks a checkbox in a form. Each time, the browser has to run whatever code is attached to that action and then draw the result on screen. INP measures how long that takes, from the tap to the next frame the visitor can see.
It watches clicks, taps and key presses throughout the visit, not just the first one, and reports a figure close to the slowest. Scrolling and hovering are not counted. If a page loads quickly but then freezes for a moment every time someone touches it, INP is the metric that catches it.
Google’s line: INP is good at 200 milliseconds or less. INP took over from an older metric, First Input Delay, in March 2024. If you want to understand why that swap happened and what INP actually counts, read what interaction to next paint measures.
Cumulative Layout Shift: did things move?
You start reading a paragraph and it slides down because an advert loaded above it. You go to tap a button and a cookie banner pushes it away, so you tap the wrong thing. That jolt is a layout shift, and CLS adds up how much visible content moved unexpectedly, and how far.
Unlike the other two, CLS is not measured in time. It is a score with no unit. Zero means nothing moved. Bigger numbers mean more of the screen jumped further. Movement that happens straight after the visitor does something, like opening an accordion they tapped, is not counted, because they expected it.
Google’s line: CLS is good at 0.1 or less. The usual causes are images without set dimensions, embeds and ad slots that reserve no space, late fonts and banners injected at the top. The post on tracking down layout shift causes covers each one.
The thresholds and the 75th percentile
Here are the three side by side.
| Metric | What it describes | Good | Unit |
|---|---|---|---|
| LCP | Main content visible | 2.5 s or less | Seconds |
| INP | Response to taps, clicks, keys | 200 ms or less | Milliseconds |
| CLS | Unexpected movement | 0.1 or less | Score, no unit |
Each metric has three bands: good, needs improvement and poor. The part most people miss is how the number for your page is chosen. Google does not average your visitors. It takes the 75th percentile of page loads.
Picture lining up every visit to a page from fastest to slowest. Go three quarters of the way along the line and read the number there. That is the figure Google judges. In plain terms: for a page to count as good, at least three out of four visits need to be good. The remaining quarter can be slower without failing you.
This matters for two reasons. First, a few unlucky visitors on a bad connection will not sink your result. Second, and more often, a site that is fast for you on office Wi-Fi can still fail because a large share of its real visitors are on mid-range phones and mobile data. The 75th percentile is deliberately set to include them.
A page passes the overall Core Web Vitals assessment when all three metrics are in the good band at the 75th percentile. One bad metric is enough to fail. If that is what you are looking at right now, the post on what a failed assessment means and what to do first is the practical next step.
Field data and lab data, briefly
There are two very different ways to get these numbers, and mixing them up causes a lot of confusion.
Field data comes from real visits. Google collects it from Chrome users who allow usage statistics to be shared, and publishes it in the Chrome User Experience Report, usually shortened to CrUX. It covers the previous 28 days, so it changes slowly. It only exists if your page or site gets enough traffic. This is the data Search Console uses, and it is the data that describes what your customers actually go through.
Lab data comes from a single test run in controlled conditions, which is what Lighthouse produces inside PageSpeed Insights and Chrome DevTools. It is repeatable and great for debugging, but it is one imaginary visitor, not your audience. A lab test cannot measure INP at all, because nobody is tapping anything during the test; it shows Total Blocking Time as a stand-in.
When the two disagree, they are usually both correct about different things. The post on why the field and lab numbers disagree explains which to use for which decision.
Where to see your own Core Web Vitals
- PageSpeed Insights. Paste a URL. The top section, if your site has enough traffic, is field data for that URL and for the whole site (the “origin”). The section below is the lab test.
- Google Search Console. Under Experience, the Core Web Vitals report groups your URLs into good, needs improvement and poor, separately for mobile and desktop. It is the best overview of a whole site. The walkthrough of the Search Console Core Web Vitals report shows how to read it.
- Chrome DevTools. The Performance panel shows your own LCP, INP and CLS live as you click around, on your device. Useful for reproducing a problem, not for judging the site.
Low-traffic sites often see “no data” or “not enough data” in the field section. That does not mean something is wrong. It means not enough Chrome users visited in the last 28 days for Google to publish a figure. You then rely on lab tests and your own testing on a real phone.
What Core Web Vitals do not tell you
They are a good summary, not a complete picture. A few things they leave out:
- Server response time and first paint. Time to First Byte and First Contentful Paint appear in the same reports, but Google treats them as diagnostic metrics, not Core Web Vitals. They help explain a bad LCP rather than standing on their own.
- Whether the page works. A page can pass all three and still have a broken checkout or a form that never sends.
- Pages without traffic. New landing pages, rarely visited service pages and staging sites will have no field data at all.
- Logged-in experience. Admin screens are not part of it, and logged-in customers on a membership site may have a very different experience from the anonymous visitors who dominate the data.
If you want the wider view of speed beyond these three measurements, the website speed guide sets out how the pieces fit together, from hosting to images to scripts.
How to use this without getting lost
None of this helps unless it changes what you do next. A short routine that works for most small business sites:
- Open Search Console’s Core Web Vitals report and look at mobile first. Note which metric is flagged and how many URLs are affected.
- Pick one example URL from the worst group and test it in PageSpeed Insights. Check the field section for that URL, then the origin.
- Write down the three numbers and the date. You will want them later, because field data takes weeks to reflect a change.
- Fix one metric at a time, starting with the one furthest from good.
- Re-test in the lab straight away to confirm the change worked, then wait for the field data to catch up before declaring victory.
The biggest mistake is chasing all three at once with a pile of plugin settings. The second biggest is judging the result the same afternoon from a single lab score. Neither tells you what your visitors are now experiencing.
Frequently asked questions
Do Core Web Vitals measure desktop and mobile separately?
Yes. Field data is split by device type, and Search Console shows separate mobile and desktop reports. It is common to pass on desktop and fail on mobile, because phones have slower processors and more variable connections. Treat the mobile result as the one that needs attention first for most small business sites.
Why does my site show a Core Web Vitals result when my own page shows no data?
PageSpeed Insights can show field data for the whole origin, meaning your domain, even when a single URL does not have enough visits of its own. The origin figure blends every page together. It is a fair guide to the site overall but can hide one slow page that drags or one fast page that flatters.
Does a better Lighthouse score automatically mean better Core Web Vitals?
Not automatically. Lighthouse runs one simulated visit, while Core Web Vitals in the field reflect thousands of real ones. Improvements usually help both, but a lab score can rise from changes real visitors barely notice, and real visitors can struggle with things a lab test never triggers, such as slow taps on a menu.
Will Google add more metrics to Core Web Vitals in future?
Google has said the set can change as it learns more about measuring user experience, and it has already replaced one metric when INP took over from First Input Delay. INP was announced as the replacement well before the switch in March 2024, which gave site owners time to prepare.
When you would rather have someone work through the three numbers with you, our website speed optimisation service lists LCP, INP and CLS among the things it covers. It runs much like the routine above: an audit, a prioritised list of fixes, changes made with your approval, then a re-test.
All guides in this section
- How to Improve Largest Contentful Paint (LCP)
- Interaction to Next Paint Explained: What INP Measures
- How to Fix Poor INP: Finding the Slow Interaction
- How to Fix Cumulative Layout Shift on Your Site
- Reading the Core Web Vitals Report in Search Console
- Field Data vs Lab Data: Which Speed Numbers to Trust
- Core Web Vitals Assessment Failed? What It Means
- Do Core Web Vitals Affect SEO? What Google Has Said
- What Is Time to First Byte (TTFB) and How to Measure It
- First Contentful Paint Explained: FCP vs LCP
Next in this series: How to Improve Largest Contentful Paint (LCP)
