Core Web Vitals Thresholds

The limits for LCP, INP and CLS, and how they're measured.

Core Web Vitals are three metrics Google uses to describe the experience of loading and using a page: Largest Contentful Paint (LCP) for loading speed, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. Each has two thresholds that split results into good, needs improvement and poor. INP took over from First Input Delay (FID) as the responsiveness metric on March 12, 2024, so any report still quoting FID is out of date.

The numbers are judged on real visits, not on a single test. Google looks at the 75th percentile of page loads from Chrome users, split into mobile and desktop, so a page only counts as good for a metric when at least three in four visits hit that metric's good threshold. Lab tools such as Lighthouse are still useful for finding the cause of a slow page, but they run one simulated load and can't measure INP. Below are the thresholds from web.dev, how the assessment works, the four parts of LCP and what Google's own documentation says about rankings.

Last reviewed October 2, 2026 against the sources below.

The thresholds

From web.dev. Each metric is judged at the 75th percentile of real page loads.

Metric	What it measures	Good	Needs improvement	Poor
LCP (Largest Contentful Paint)	Loading: when the largest image, text block or video in the viewport has rendered	2.5 s or less	Over 2.5 s up to 4 s	Over 4 s
INP (Interaction to Next Paint)	Responsiveness: the delay between a click, tap or key press and the next frame the page paints	200 ms or less	Over 200 ms up to 500 ms	Over 500 ms
CLS (Cumulative Layout Shift)	Visual stability: how much visible content moves unexpectedly while the page is in use	0.1 or less	Over 0.1 up to 0.25	Over 0.25

How the assessment works

Rule	Detail
75th percentile	Each metric is judged at the 75th percentile of real page loads, so at least three in four visits must hit the good threshold for the metric to count as good.
Mobile and desktop separately	Page loads are split by device type, and each segment is assessed on its own. A page can be good on desktop and poor on mobile.
Page and origin	Chrome's UX Report (CrUX) aggregates data per page and per origin (protocol, host and port). PageSpeed Insights shows both levels.
URL groups in Search Console	Search Console's report groups URLs with a similar experience and gives a group the status of its slowest metric. If URLs lack data, they can fall into a wider origin group.
Who is counted	Only pages that are publicly discoverable (200 status, no noindex) and get enough real Chrome visitors appear in CrUX. Low-traffic pages may have no field data at all.

The four parts of LCP

web.dev splits LCP into four parts; the shares are its rough guide for a well-optimized page.

Subpart	What it covers	Rough share
Time to First Byte (TTFB)	From the start of navigation until the first byte of the HTML arrives	About 40%
Resource load delay	From TTFB until the browser starts loading the LCP image (zero for a text LCP element)	Under 10%
Resource load duration	The time to download the LCP resource itself	About 40%
Element render delay	From the resource finishing until the LCP element is actually painted	Under 10%

Field and lab tools

Tool	Data	Use it for
Chrome UX Report (CrUX)	Field data from real Chrome users	The dataset behind Google's field numbers, via the CrUX API or BigQuery
PageSpeed Insights	Field (CrUX) and lab (Lighthouse)	A page's and its origin's real-user metrics on mobile and desktop, plus lab diagnostics
Search Console Core Web Vitals report	Field data (CrUX), grouped by similar URLs	Finding which templates or sections of your own site need work
web-vitals JavaScript library	Field data from your own visitors	Collecting LCP, INP and CLS in your analytics (real-user monitoring)
Lighthouse	Lab data, one simulated load	Debugging. It reports Total Blocking Time instead of INP, because INP needs real interactions
Chrome DevTools Performance panel	Lab data from your own session	Tracing a slow load or interaction step by step

What Google says about rankings

Common claims, checked against Google Search Central.

Claim	What Google's documentation says
Core Web Vitals are a ranking factor	Google says Core Web Vitals are used by its ranking systems, as part of a wider page experience, and that there is no single page experience signal.
Good scores will get me to the top	No. Google says good results in the Core Web Vitals report or third-party tools don't guarantee top rankings.
Speed beats relevance	No. Google says it always tries to show the most relevant content even if the page experience is poor; page experience matters more when many pages are similarly helpful.
Lab scores are what count	Google's report and assessment use field data from real Chrome users (CrUX). Lab tools like Lighthouse are for diagnosing problems.
FID still matters	No. INP replaced First Input Delay as a Core Web Vital on March 12, 2024. Search Console dropped FID that day, and other tools after a six-month deprecation period.

Good to know

TTFB isn't a Core Web Vital

Time to First Byte is the first part of LCP, and web.dev suggests 0.8 seconds or less as a rough guide, but it isn't a Core Web Vital itself. A slow TTFB matters because it leaves less time for everything else before the 2.5-second LCP mark. Redirect chains and uncached responses are common causes.

Why field and lab numbers differ

Field data covers many devices, networks and visits over time; a lab test is one load on one simulated device. Use field data to decide whether there's a problem and lab tools to find out why. Pages with little traffic may have no field data at all.

Sources

Search engines and AI companies change their documentation often; check the source before relying on a detail.