SEO · 10 min read
What LCP, INP and CLS measure, and how they are assessed
Three metrics, three thresholds and one assessment rule that explains most of the confusion: the judgement is made at the 75th percentile of real visits, not on a score produced by a testing tool. Here is what each one records, and why your page may have no data at all.
Written by Zubair Afzal, FounderUpdated
The three metrics
Three separate complaints, expressed as numbers
Each metric corresponds to a distinct thing a visitor would say out loud. Reading them that way makes the reports much easier to act on.
LCP — "it took ages to show up"
Largest Contentful Paint records how long it took for the largest piece of content in the visible area — usually a hero image, a heading block or a banner — to be painted, measured from when the page started loading. It is a loading measure, and the largest element is frequently not the one anyone thought was important.
INP — "I tapped it and nothing happened"
Interaction to Next Paint observes the latency of interactions and reports a value nearly all of them were beneath. Only clicks, taps and key presses count. It spans input delay before any handler runs, the time the handlers take, and the delay before the next frame is presented.
CLS — "it moved while I was reading it"
Cumulative Layout Shift measures the largest burst of unexpected layout movement during the whole life of the page. A burst, in the documentation, is a run of shifts less than a second apart, capped at five seconds in total. Late-loading images, injected banners and web fonts are the usual causes.
The numbers
The published thresholds, and the rule that binds them
These four figures are the whole assessment. Every argument about Core Web Vitals is really an argument about one of them.
- LCP target — the largest visible element should be painted within this
2.5s
LCP target — the largest visible element should be painted within this
- INP target — pages should have an INP of this or less
200ms
INP target — pages should have an INP of this or less
- CLS target — pages should maintain a score of this or below
0.1
CLS target — pages should maintain a score of this or below
Source: web.dev: Cumulative Layout Shift
- The percentile of page loads all three are judged at, split by device
75th
The percentile of page loads all three are judged at, split by device
Source: web.dev: Core Web Vitals
The percentile is the part that changes how you work. Passing means three quarters of real visits came in under the threshold, so the visits that decide the outcome are the slow ones: older phones, poor connections, congested networks, and people whose devices are already busy. Improving the experience for the fastest half of your audience moves nothing.
How the judgement is made
Where the numbers come from, and why your page might not have any
The assessment is built from what real Chrome users experienced, not from a test. That is the source of nearly every disagreement between a green testing score and a failing report, and it is why the fix that improves a lab number sometimes changes nothing at all.
Not every page is measured individually. The Chrome UX Report documentation sets two conditions for inclusion: the page or origin must be publicly discoverable, judged by the same sort of criteria as search indexability, and it must be sufficiently popular, meaning it has enough visitors to report on without identifying anybody. Pages returning a non-200 status, or carrying a noindex instruction in a header or a meta tag, are not eligible.
When a page does not qualify on its own, its visits still contribute to the figures for the whole origin. The documentation notes that if an origin is publicly discoverable, eligible experiences across all of its pages are aggregated at origin level regardless of whether each individual page qualifies. So a report can be describing your entire site while appearing to describe one page, and a template you have never looked at can be the reason a page you have optimised still reads as failing.
One further detail catches people out: query parameters and fragments are stripped, so all the variants of an address are aggregated together. A campaign landing page and its twenty tagged variants are one page as far as the data is concerned.
Metric by metric
What each one records, and what actually moves it
The causes are genuinely different, which is why a single performance sprint often fixes one metric and leaves the other two exactly where they were.
| Dimension | LCP | INP | CLS |
|---|---|---|---|
| What it records | Render time of the largest visible content element, from when loading started. | The latency of interactions, reported as a value nearly all of them were beneath. | The largest burst of unexpected layout movement, scored rather than timed. |
| When it is recorded | Once, during load. | Throughout the visit, whenever somebody clicks, taps or types. | Across the entire lifespan of the page, including long after load. |
| What the visitor experiences | A blank or skeleton screen for longer than they expected. | A tap that appears to do nothing, so they tap again. | Text or a button jumping as they reach for it. |
| Most common cause | Slow server response, render-blocking resources, or an unoptimised hero image. | Long tasks on the main thread — heavy handlers, hydration, third-party scripts. | Images and embeds without reserved space, late banners, and font swaps. |
| What genuinely improves it | Faster first byte, prioritising the element that is actually largest, and serving it in a sensible format and size. | Shipping less JavaScript, breaking up long tasks, and removing or deferring third-party tags. | Explicit dimensions on media, reserved space for anything injected, and a font strategy that does not reflow. |
| Where lab tools mislead | A simulated connection can be kinder or harsher than your real audience. | A synthetic run does not interact with the page, so it can only estimate. | Lab runs mostly see load-time shifts, so a page that misbehaves on scroll looks clean. |
Reading the report
Four ways a Core Web Vitals report gets misread
- The performance score is treated as the assessment.
- A performance score out of a hundred is a weighted summary of several lab measurements, several of which are not Core Web Vitals at all. It is a useful diagnostic and it is not the thing being assessed. A page can score in the nineties and fail, and a page can score poorly and pass, and both happen often enough that quoting the score in a status report is close to meaningless.
- The homepage was tested and the answer applied to the whole site.
- Homepages are the most optimised page on almost every site and the least representative. The pages that carry commercial value are usually product, article or location templates, built at different times by different people. Assess by template, on the pages that actually receive visits, and expect the answers to differ.
- "No data available" is read as a pass.
- It means the page has not met the eligibility conditions for individual reporting — most often that not enough people have visited it. That is an absence of evidence, and treating it as evidence of absence is how a slow but important landing page goes unexamined for a year.
- The fix shipped and the report did not move, so the fix was judged a failure.
- The assessment summarises a period of real visits, so it changes gradually as older experiences age out of the window. If you need to know sooner, measure the metrics yourself in your own analytics on live traffic. That gives you an answer in days instead of waiting for a report you do not control.
Before committing engineering time
Six things to establish before anybody starts optimising
Performance work is expensive and easy to aim at the wrong target. These six answers usually reduce the scope by more than the work itself would.
- Which templates the failing pages belong to, and how much traffic and revenue each template carries. Fixing an unvisited template is a real cost with no return.
- Which of the three metrics is actually failing, per template and per device class. The three have almost nothing in common in terms of remedy.
- What the largest visible element actually is on each failing template. It is frequently not the thing the design treats as the hero.
- What the third-party scripts cost. Measure each tag’s main-thread time individually, then decide which ones survive that conversation with the people who asked for them.
- Whether the page is eligible for its own field data at all, or whether you have been reading site-wide figures and attributing them to one page.
- Whether real-user measurement is running in your own analytics. Without it you are waiting on an external report to find out whether your work helped.
Questions
Questions people ask when the report says fail
What are Core Web Vitals?
Three measurements of how a page behaves for the people using it: Largest Contentful Paint for loading, Interaction to Next Paint for responsiveness, and Cumulative Layout Shift for visual stability.
They are deliberately experiential rather than technical. Each corresponds to a complaint somebody would make out loud — it took too long to appear, I tapped it and nothing happened, it moved while I was reading it — which is why they are judged on real visits rather than on a test.
What counts as passing?
web.dev states that a page should be considered passing if it meets the recommended targets at the 75th percentile for all three metrics. The targets are 2.5 seconds for LCP, 200 milliseconds for INP and 0.1 for CLS.
All three, at the 75th percentile, segmented by mobile and desktop. Two out of three is not a pass, and a good average is not a pass either — the whole point of the percentile is that averages hide the visits that were bad.
Why does our page have no field data?
Because it has not met the eligibility conditions. The Chrome UX Report documentation states that a page or origin must be publicly discoverable and sufficiently popular, and pages returning a non-200 status or carrying a noindex directive do not qualify.
When a page is not individually eligible, you are usually looking at data aggregated for the whole origin instead. That is worth knowing before anybody concludes their page is failing: the number may be describing the site rather than the page.
Why does Lighthouse disagree with Search Console?
They are measuring different things. Lighthouse runs a single simulated visit under a fixed set of conditions and produces a weighted score. The Core Web Vitals assessment summarises what real visitors experienced on their own devices and connections.
When they disagree, the field data is the one that counts and the lab data is the one that tells you why. Use the score to find the cause, and the field data to decide whether it was worth fixing.
Does scrolling count towards INP?
No. web.dev states that INP observes clicks, taps and key presses. Scrolling and hovering are not counted, which surprises people who assume a janky scroll will be reflected in the number.
INP reports a value that nearly all interactions were beneath — for most sites, the worst one, with an allowance of one outlier per fifty interactions on pages with many. So a single very slow interaction on a low-traffic page can define the metric.
How much does this actually affect our position in search?
Modestly, and anyone claiming otherwise is overselling. Google documents Core Web Vitals as part of how page experience is considered, alongside a great many other signals, and has been consistent that useful content is the larger factor.
The stronger argument is usually commercial rather than positional. A page that loads slowly on a mid-range phone on mobile data loses people before it can convert them, and that cost is measurable in your own analytics without reference to rankings at all.
Our visitors are mostly on desktop. Does this still matter?
It matters less, and it is worth checking rather than assuming. The assessment is segmented by device class, so a genuinely desktop audience is judged on desktop experiences.
Two cautions. Analytics under-counts mobile visitors who left before the page was usable, so the split you see may already be a consequence of the problem. And the desktop thresholds are the same numbers, which means a heavy application can fail on a good machine as easily as a light page fails on a phone.
Want to know which template is actually costing you
Most sites have two or three templates doing the damage and a long tail that does not matter. We can tell you which is which before anybody commits development time to it.
Last updated