Core Web Vitals thresholds and what counts as passing
The published good, needs improvement and poor boundaries for every Core Web Vital and its supporting metrics, plus how the 75th percentile rule works.
A page passes Core Web Vitals when it meets three thresholds at the 75th percentile of real visits. Largest Contentful Paint is 2.5 seconds or less, Interaction to Next Paint is 200 milliseconds or less, and Cumulative Layout Shift is 0.1 or less (web.dev). Mobile and desktop are assessed separately.
Every number on this page is a boundary Google publishes, not an average anybody measured. That makes the numbers reliable. It also makes them easy to misread, because passing a threshold is not the same as being fast.
The short version
- The good thresholds are LCP 2.5 seconds or less, INP 200 milliseconds or less and CLS 0.1 or less. Poor starts above 4 seconds, 500 milliseconds and 0.25.
- Each metric is judged at the 75th percentile of page loads, so three in four visits must meet the target (web.dev).
- PageSpeed Insights reports real-user data over the previous 28 days, and falls back to data for the whole site when a single page has too few visits (PageSpeed Insights).
- INP replaced First Input Delay as a Core Web Vital on 12 March 2024, and FID was retired (web.dev).
- FCP and TTFB are diagnostic metrics with their own thresholds. They are not Core Web Vitals.
- Google says Core Web Vitals are used by its ranking systems, and that good scores do not guarantee top rankings (Google Search Central).
What are the Core Web Vitals thresholds?
These are the three metrics Google counts as Core Web Vitals, with the boundaries it publishes for each (LCP, INP, CLS on web.dev).
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP | Time until the largest image, text block or video in the viewport has rendered | 2.5s or less | 2.5s to 4.0s | Over 4.0s |
| INP | Latency of the slowest interaction in the visit, ignoring rare outliers | 200ms or less | 200ms to 500ms | Over 500ms |
| CLS | Largest burst of unexpected layout movement | 0.1 or less | 0.1 to 0.25 | Over 0.25 |
Each is assessed at the 75th percentile of real page loads, mobile and desktop separately. PageSpeed Insights and Search Console use Chrome User Experience Report data from the previous 28 days.
INP is worth a sentence of its own. It watches every click, tap and key press during the visit and reports the longest one. On pages with many interactions it ignores one of the slowest for every 50, so a single hiccup does not decide the result (web.dev).
Which supporting metrics are not Core Web Vitals?
First Contentful Paint and Time to First Byte have published thresholds but do not decide whether a page passes. They are there to help you find the cause of a slow LCP.
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| FCP | Time until the first content of any kind appears | 1.8s or less | 1.8s to 3.0s | Over 3.0s |
| TTFB | Time until the first byte of the response arrives | 800ms or less | 800ms to 1800ms | Over 1800ms |
Sources: FCP and TTFB on web.dev. The TTFB page says plainly that TTFB is not a Core Web Vital, so a site does not have to meet its good threshold as long as the metrics that count still pass.
Which metrics have been retired?
| Metric | Status | Replaced by |
|---|---|---|
| FID, First Input Delay | Retired as a Core Web Vital on 12 March 2024 | INP |
| Total Blocking Time | Lab metric only, never a Core Web Vital | INP in the field |
FID still appears in older articles and some tools. Google retired it when INP became a Core Web Vital (web.dev). Total Blocking Time is a lab metric that web.dev describes as a useful indicator of INP problems in testing, with real INP measured in the field (web.dev).
How does the 75th percentile rule work?
A page is not judged on its average. It is judged on the visit three quarters of the way down the list, sorted from fastest to slowest. Google chose that point so that three in four visits get the target experience or better, and so that a few extreme outliers do not decide the result (web.dev).
This works in both directions. A handful of very slow loads will not fail you, because they sit beyond the 75th percentile. A consistently mediocre quarter of your traffic will, even if the median looks fine.
It also means your own experience of your own site is weak evidence. You are probably on a fast connection and a good device, with the site already cached. Your visits are likely to be among the fastest the site gets.
Photo: Mathias Reding on Pexels.
Why does my site pass on desktop but fail on mobile?
Because they are two separate assessments, not one average. Search Console’s Core Web Vitals report evaluates mobile and desktop separately, and a group of URLs takes the status of its worst metric (Search Console Help).
Phones usually have less processing power and a worse connection, and images are often served at desktop sizes. PageSpeed Insights’ lab test reflects this by simulating a mid-tier phone on a mobile network (PageSpeed Insights). For many small business sites the mobile assessment is the one to watch, because it tends to fail first. Your analytics will tell you whether most of your visitors are on phones.
What happens when a page has no field data?
Core Web Vitals field data comes from real Chrome users, and a page needs enough of them to be reported. Google does not publish the minimum (Chrome UX Report).
Below that level, PageSpeed Insights falls back to origin data, which covers every page on the site, and Search Console groups the URL into a larger origin group. For a small site, the report for a quiet page may really describe the site as a whole. Knowing which one you are looking at changes what you should do.
How should you use these numbers?
- Read field data before lab data. PageSpeed Insights shows both, and only the field section reflects real visitors. A perfect lab score with failing field data means your test conditions are not your visitors’ conditions.
- Treat the boundary as a floor, not a target. A page that sits just inside good has no margin, and one heavy image or new script can push it over.
- Check mobile separately and expect it to be worse.
- When a page has no field data, that is information, not a pass. You are looking at origin-level numbers or nothing.
Photo: Castorly Stock on Pexels.
What does passing not tell you?
The classification is a floor. Everything from zero to 2.5 seconds counts as good, and the difference between the two ends of that range is large for someone waiting on a phone with one bar of signal.
- Passing is a classification, not a measure of quality. A page at 2.4 seconds and a page at 0.9 seconds are both good, and the second is better for the person waiting.
- The 75th percentile is taken from real visits, so a site with fast visitors on good connections can pass while being heavy to load. A well-built site serving a slower audience can fail.
- Low-traffic pages fall back to origin data or have none, so the report may describe the site rather than the page in front of you.
- Thresholds have changed before. FID was retired in March 2024, so check any figure quoted from before then.
If you are optimising for enquiries rather than a badge, keep going after you pass. If you stop at the boundary, you are one deployment away from failing again.
Where do these figures come from?
They are not measured figures. They are the classification boundaries Google publishes for each metric on web.dev, and the reporting rules PageSpeed Insights and Search Console apply to Chrome User Experience Report data. We gathered none of them, and no figure here describes the typical speed of any site or industry. There is no sample, period or margin of error to report, because the thresholds are definitions applied the same way to every site. Last checked against the sources on 2026-09-30.
The bottom line
The thresholds tell you where Google draws the line, measured on three quarters of real visits, on phones and computers separately. Treat them as the minimum. The speed your visitors feel on a slow phone is what they actually notice.
Questions people ask about this
Do Core Web Vitals actually affect rankings?
Google says Core Web Vitals are used by its ranking systems and that there is no single page experience signal. It also says it still shows the most relevant content even when page experience is below par. Our reading is that fixing them will not rescue a page that does not deserve to rank, and failing them badly can cost you against a close competitor. The stronger argument for fixing them is conversion rather than ranking, because the same slowness that fails the threshold also loses you enquiries.
Why does my PageSpeed score differ from my Core Web Vitals assessment?
Because they are different things. The score out of 100 is a lab measurement from a simulated device on a simulated connection, run once. The Core Web Vitals assessment is field data from real Chrome users over 28 days. A site can score 98 in the lab and fail in the field, and that combination usually means the test environment is faster than your visitors.
How long after a fix before the assessment changes?
The field data uses a rolling 28 day window, so a fix deployed today is fully reflected roughly a month later. Partial improvement appears sooner as the window fills with post-fix visits. If nothing has moved after six weeks, the fix probably did not work for real users, whatever the lab tool says.
Where do I find my field data?
Two places. PageSpeed Insights shows it at the top of the report for a single URL, labelled as real user data, with the lab section underneath. Search Console shows it for the whole site in the Core Web Vitals report, grouped by status and by the URL patterns affected. Use Search Console to find which pages are failing and PageSpeed Insights to see why.
Which metric should I fix first?
Whichever one is failing at the 75th percentile on mobile. If more than one fails, LCP often pays back fastest, because the causes are common and visible: an oversized hero image, a slow server response or a render-blocking script. CLS is often a single element with no reserved space. INP tends to be the hardest, since it points at script work across the visit.
Why does my site pass on desktop and fail on mobile?
Because the assessments are separate and mobile visits are slower. Phones have less processing power, images are often served at desktop sizes, and the connection is worse. The same page that renders in a second on a laptop can take four on a phone with one bar. Test on a real phone on mobile data rather than in a desktop browser with a resized window.
What is a good TTFB target for a small site?
Inside the good boundary in the table, and the lower the better, because everything else waits for it. A slow first byte usually points at hosting, a heavy theme or plugins running on every request, or no caching. Check whether your host serves pages from a cache and whether a content delivery network sits in front of it. In the sites we look at, those two changes are where a slow TTFB is most often fixed.
Can a plugin or theme change fail me overnight?
Yes. It is one of the causes we see most often. A new chat widget, a tracking script, a slider or a font change can push LCP or CLS over the boundary for every page at once. The assessment takes weeks to reflect it, so the cause is often forgotten by the time it shows. Run a PageSpeed test before and after any change to the template.
Should I care about INP if my site is mostly static?
Less than a site full of interactive elements, but not zero. INP observes every click, tap and key press, including menu taps and cookie banner clicks, and a heavy script bundle can make even those slow. If the field data shows INP passing comfortably, move on. If it is close to the boundary, look at third-party scripts first, since they are usually the ones doing the work.
My page has no field data. What do I do?
Read the origin-level data, which describes the site as a whole, and treat the lab report as your only page-level signal. Fix the obvious things the lab report shows. Then concentrate on the pages that do have data, since they carry the traffic. A page with no data has no assessment to fail, but it also has no visitors to convert.
Does passing Core Web Vitals make my site fast enough?
Not necessarily. The good boundary is a floor, and a page at the top edge of it is still slow for a visitor on a weak connection. If enquiries matter more than the badge, keep testing on a real phone and aim well inside the boundary. That margin is also what stops one heavy image from tipping you back into failing.
Free review
Want this looked at on your own site?
Send the address. A person reads it and writes back with the two or three things that would move your enquiry number first. Free, and yours to keep whether you hire us or not.
