What is a "good" Core Web Vitals score?
There's no single Core Web Vitals score. Google reports three independent metrics — LCP, INP, CLS — and "good" is defined per metric, at the 75th percentile, by Google itself. Here's exactly what counts as good, where the line is, and what most real sites actually look like.
The thresholds — exact, official
These thresholds come straight from web.dev and are the numbers Google uses for its page-experience signal.
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP (Largest Contentful Paint) | ≤ 2.5s | 2.5s – 4.0s | > 4.0s |
| INP (Interaction to Next Paint) | ≤ 200ms | 200ms – 500ms | > 500ms |
| CLS (Cumulative Layout Shift) | ≤ 0.1 | 0.1 – 0.25 | > 0.25 |
To pass Core Web Vitals, all three must be in the "good" bucket. One metric in "needs improvement" or "poor" fails the whole bundle.
What "at p75" actually means
The thresholds apply at the 75th percentile of real user experiences. That means: take all the LCP times you measured across all users in the last 28 days, sort them, and look at the 75th-percentile value. That value has to be ≤ 2.5s for LCP to count as "good."
The practical implication: even if your median LCP is 1.4s, if 30% of users see 5s+ on flaky mobile, your p75 LCP is poor and you fail. CrUX is unforgiving about long tails — you can't average them away.
What real sites look like
Most production sites we've checked sit somewhere in this range:
- LCP: 2.0–4.0s on mobile is normal. Sites under 1.5s are usually static or aggressively cached.
- INP: 100–300ms is normal. Heavy React or Vue apps with poor splitting frequently hit 400ms+.
- CLS: 0.05–0.20 is normal. The biggest offenders: images without dimensions, fonts that swap, ads that load late.
If you're at "good" on all three at p75, you're better than ~30-40% of the public web.
"Good" vs "perfect" — diminishing returns
Once you cross the "good" threshold, every additional millisecond of improvement matters less. Going from poor (5s LCP) to good (2.5s LCP) is huge for users and rankings. Going from 2.5s to 1.5s helps users but doesn't change your Core Web Vitals pass/fail.
The Google ranking signal is binary-ish: did all three pass at p75? Yes or no. There's no extra credit for being twice as fast as the threshold. So budget your effort: get every metric across the line, then move on to content quality.
Mobile vs desktop
Google uses mobile for ranking (mobile-first indexing since 2019). Your desktop LCP can be 800ms and it won't save you if mobile LCP is 4.5s. Check the mobile vs desktop split — that's the number that matters for SEO.
Common patterns we see
Sites that pass on desktop but fail on mobile — usually a JavaScript bundle problem. The same code runs fast on M-series chips, slow on $100 Android. Fix: split bundles, defer non-critical JS, use Next.js streaming.
Sites that pass LCP and CLS but fail INP — usually a third-party scripts problem. Chat widgets, A/B testing tools, and analytics tags pile up on the main thread. Fix: audit every script, lazy-load the ones that don't fire above the fold, move to Web Workers where you can.
Sites that have great vitals but no rankings — vitals are a tiebreaker, not a primary ranking factor. If you're behind on content quality, no amount of LCP optimization will help. See does page speed affect Google rankings.
How to check your own site
Search your domain on this site to get the live CrUX numbers. We use the official Google CrUX API, normalized to https, and we show all three Core Web Vitals plus FCP and TTFB — across mobile, desktop, and combined.
If your domain returns "No CrUX data," it means Google doesn't have enough Chrome users hitting it yet. The threshold for inclusion is undocumented but seems to be roughly tens of thousands of unique users per month.
By Paulo de Vries · Published