What is Core Web Vitals?
Core Web Vitals are Google’s three user-experience metrics — LCP for loading, INP for responsiveness and CLS for visual stability — measured on real users.
Core Web Vitals are three metrics Google uses to measure how a page feels to real visitors: how fast the main content appears, how quickly the page reacts to input, and how stable the layout stays while it loads. They were defined by Google’s Chrome team and are documented on web.dev.
The three metrics and their thresholds
| Metric | Measures | Good | Poor |
|---|---|---|---|
| LCP — Largest Contentful Paint | Loading: when the largest visible element renders | ≤ 2.5 s | > 4 s |
| INP — Interaction to Next Paint | Responsiveness to clicks, taps and key presses | ≤ 200 ms | > 500 ms |
| CLS — Cumulative Layout Shift | Visual stability | ≤ 0.1 | > 0.25 |
INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. FID only measured the delay before the first interaction; INP looks at responsiveness throughout the whole visit.
Field data at the 75th percentile
A page passes when at least 75% of real visits meet the “good” threshold for each metric. That data comes from the Chrome User Experience Report (CrUX), collected from Chrome users who opted in, and it is evaluated separately for mobile and desktop. Pages without enough traffic are judged with similar pages in Search Console, and PageSpeed Insights may show origin-wide data instead.
That explains a common puzzle: a perfect Lighthouse score on your laptop can sit next to a failing Search Console report. Lab tests simulate one load on one device; field data reflects your actual audience on mid-range phones and patchy networks.
Do they affect rankings?
Google says Core Web Vitals are used by its ranking systems as part of page experience, while stressing that relevance and content quality matter more (Core Web Vitals and Google Search). Treat them as a tie-breaker for search and, more importantly, as a business metric: slow, jumpy pages lose visitors whatever their position.
A sensible order of work
- Open the Core Web Vitals report in Search Console and find the failing URL groups.
- Pick the template with the most traffic — often product or article pages, not the homepage.
- Fix the worst metric first, then re-measure in the lab before releasing.
- Wait for field data to catch up; CrUX uses a rolling 28-day window.
Common mistakes
- Optimizing only the homepage while other templates carry most visits.
- Testing on desktop broadband when most visitors use phones.
- Declaring victory the day after a fix, before field data reflects it.
- Adding a chat widget or a new tag manager container after the audit and quietly undoing the gains.
Measure yours
The page speed test reports server response time, page weight, render-blocking resources and caching, plus Core Web Vitals (LCP, INP, CLS) from Google PageSpeed Insights when field data is available for the URL.
Frequently asked questions
What replaced First Input Delay?
Interaction to Next Paint (INP) replaced FID as a Core Web Vital in March 2024. INP measures the responsiveness of all interactions during a visit, not just the first one.
Why does PageSpeed Insights show no field data for my page?
Field data requires enough visits from Chrome users who share usage statistics. Low-traffic pages may show origin-level data or nothing, in which case lab results are your best guide.
Is TTFB a Core Web Vital?
No. Time to First Byte is a diagnostic metric. It strongly affects LCP, though, because nothing can render until the first byte of HTML arrives.