Core Web Vitals are 3 measurements of how a page feels to use: how fast the main content loads, how quickly it responds to input, and how much it jumps around. The good thresholds are 2.5 seconds for loading, 200 milliseconds for responsiveness, and 0.1 for layout shift, measured at the 75th percentile of real page loads.
The 3 metrics and their thresholds
These figures come from web.dev, Google’s developer site for web performance. As of its last update on the overview page, the current set focuses on loading, interactivity, and visual stability.
| Metric | Measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| Largest Contentful Paint (LCP) | Loading | 2.5 seconds or less | Above 2.5 up to 4 seconds | Above 4 seconds |
| Interaction to Next Paint (INP) | Responsiveness | 200 milliseconds or less | Above 200 up to 500 milliseconds | Above 500 milliseconds |
| Cumulative Layout Shift (CLS) | Visual stability | 0.1 or less | Above 0.1 up to 0.25 | Above 0.25 |
The poor bands come from web.dev’s page on defining the thresholds. The same page explains the classification rule. If at least 75% of page views meet the good threshold, the site counts as good for that metric. If at least 25% of page views fall in the poor range, it counts as poor.
How each one is measured
LCP reports the render time of the largest image, text block, or video visible in the viewport, relative to when the person first navigated to the page. The elements it considers are limited on purpose: <img> elements, images inside SVG, video poster images or first frames, elements with a CSS background image loaded through url(), and block-level elements holding text. The largest element can change as the page loads, so the browser keeps updating the candidate until the person interacts. web.dev points out that LCP includes time from the previous page unloading, connection setup, redirects, and server response, which is why field and lab numbers differ.
INP looks at the latency of all clicks, taps, and keyboard interactions during a visit and reports a single value that all or nearly all of them were beneath. In practice it is the longest interaction, with outliers ignored: for pages with many interactions it ignores 1 highest interaction for every 50. A low INP means the page responded quickly consistently, not just on the first tap.
CLS is the largest burst of layout shift scores across the page’s life. A layout shift happens any time a visible element changes position between rendered frames. A burst, called a session window, is a run of shifts with less than 1 second between them, capped at 5 seconds in total. The largest window sets the score.
Where the numbers come from
The thresholds are not arbitrary, and web.dev explains the reasoning. They draw on research into human perception, which it says is usually expressed as a range of values, not a single cutoff. They also have to be achievable. Google required that at least 10% of origins in the Chrome User Experience Report meet a candidate “good” threshold, and it checked that well-optimized sites meet it consistently. For LCP, it found 1.5 and 2 seconds were not consistently achievable for top-performing sites, while 2.5 seconds was.
The same thresholds apply to mobile and desktop. web.dev says expectations of a good experience do not depend on the device, so it did not set separate numbers, and notes that most thresholds are therefore set from what is achievable on mobile. A site can pass a desktop test and still fail for the phones that web.dev says often make up the majority of traffic.
What counts as passing
web.dev says a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices. A page passes if it meets the recommended target at the 75th percentile for all 3 metrics. In plain terms, at least 3 out of 4 real visits need to meet the target, and a page that is fast on 2 metrics and slow on the third still fails.
The metrics are also not frozen. web.dev describes a lifecycle: experimental, pending, then stable. It says stable metrics will not change more than once a year, and that a stable metric can still be retired. That already happened to First Input Delay, which INP replaced in 2024.
Field data and lab data
Core Web Vitals are field metrics first, which means they describe real visits by real people. The main source is the Chrome User Experience Report, which also feeds PageSpeed Insights, Chrome DevTools, and the Core Web Vitals report in Search Console. web.dev recommends sites also set up their own real-user monitoring, because the public data does not give per-visit detail for diagnosing regressions.
Lab tools such as Lighthouse load a page in a simulated setting. web.dev says lab measurement is the best way to test features before release and catch regressions, and also that it is not a substitute for field measurement. Lab tools cannot measure INP, because there is no user to click anything. Total Blocking Time stands in for it in the lab.
This is why a perfect Lighthouse score can sit beside a failing field report. Your laptop on office Wi-Fi is not your customer’s phone on a train.
What Google says about search
Google’s Search documentation says it highly recommends site owners achieve good Core Web Vitals for success with Search and for a great experience generally, and that this, together with other page experience aspects, aligns with what its core ranking systems seek to reward. It does not say how much weight they carry or give a ranking formula. Good scores will not rescue weak content. Bad scores can make a good page frustrating to use.
A practical order of work
- Look at field data first. Open the Core Web Vitals report in Search Console or PageSpeed Insights and find the page groups that fail.
- Identify which metric fails. The fixes differ. Slow LCP is usually a heavy hero image, a slow server response, or content that waits on scripts. High INP usually means long tasks blocking the main thread. High CLS usually means images, ads, or embeds without reserved space.
- Fix 1 template at a time and watch the field data, which lags because it is aggregated over time.
- Use lab tools to verify each change in development, then confirm in the field.
Our guide to fixing Core Web Vitals goes through the common causes for each metric and the checks that confirm a fix.
