Performance
What Core Web Vitals are (and what they actually measure)
LCP, INP and CLS measure loading, responsiveness and stability on real visits. Here are the thresholds, where the data lives and what the metrics miss.
Key points
- LCP, INP and CLS measure loading, responsiveness and stability, not the quality of the content.
- The thresholds apply to the 75th percentile of real visits, split between mobile and desktop.
- Without Chrome UX Report field data you can only measure in the lab: say so.
Core Web Vitals are three Google metrics that measure a real page: LCP for loading, INP for responsiveness and CLS for visual stability. They measure neither design quality nor whether the content is right.
The three metrics and their thresholds
| Metric | What it measures | Good | Needs work |
|---|---|---|---|
| LCP | Load time of the largest visible element | ≤ 2.5 s | > 4 s |
| INP | Latency between an input and the next frame | ≤ 200 ms | > 500 ms |
| CLS | Unexpected movement of the layout | ≤ 0.1 | > 0.25 |
The thresholds apply to the 75th percentile of visits, split between mobile and desktop. Google publishes the values on web.dev and computes them from Chrome UX Report field data.
Where to read the numbers
Field data comes from the Chrome UX Report: real users, the last 28 days. Lab data comes from Lighthouse or WebPageTest: one run under declared conditions. They answer different questions: the field decides whether a page passes, the lab explains why.
npx lighthouse https://example.com --only-categories=performance --preset=desktop --output=json --output-path=./lighthouse.jsonThe command needs Node and a network connection; it writes a JSON report with LCP, CLS and TBT. Lighthouse does not measure INP: for responsiveness use field data, or a trace in the Performance panel.
What they do not measure
They do not measure accessibility, content or conversion. They are not the only ranking signal either: Google uses them inside page experience, with less weight than relevance. A fast page with the wrong answer still loses.
The limitation you have to name
A site with little traffic never enters the Chrome UX Report. Field Core Web Vitals then do not exist and you only see the lab: you cannot claim a pass that no user has measured.
Three fixes that move the numbers
- LCP: find the largest element with Lighthouse, then deliver it as an optimised image or as text. Source: web.dev, CC BY 4.0.
- CLS: give every image a width and height, and reserve space for fonts and banners.
- INP: break long tasks and defer non-critical JavaScript.
Where to continue
The EneUI catalogue indexes 111,985 components and 1,556 blocks with previews. The record image auto slider is the kind of component to check before you install it: when its images have no dimensions, CLS rises. To fix layout shift read images without dimensions, for JavaScript weight one import that grows the bundle, and for the measured comparison of libraries React libraries 2026.
Frequently asked questions
What is the difference between LCP, INP and CLS?
LCP measures how long the largest visible element takes to appear, INP measures the latency of the response to an input, and CLS measures how much the layout moves unexpectedly. They cover three different parts of the same visit.
Did INP replace FID?
Yes. INP became a Core Web Vital on 12 March 2024 and replaced First Input Delay, which measured only the delay of the first input.
Are Core Web Vitals a ranking factor?
Yes, through page experience, but with less weight than relevance and content quality. A slow page can rank if it answers better than its competitors; a fast empty page does not.
Should I read lab data or field data?
To decide whether a page passes, read Chrome UX Report field data. Lab data tells you which part of the page causes the problem.
How often do the values change?
Field data follows a rolling 28-day window, so it moves slowly. Lighthouse measures a single run and changes on every run: never compare two isolated runs.