Core Web Vitals Checker

Check page speed + Core Web Vitals (mobile/desktop) with prioritized fixes, via Google PageSpeed Insights. Free, no API key.

Core Web Vitals Checker that separates lab guesses from real Chrome data

We run the full PageSpeed Insights v5 report: all four Lighthouse categories, not just performance, plus the Chrome UX Report field data behind the pass/fail Core Web Vitals assessment. Every metric is labelled lab or field, and told apart from the 0–100 score, because those are two different tests that frequently disagree with each other on the same page.

Full Lighthouse: Performance + SEO + Accessibility + Best Practices28-day CrUX field dataLab vs field, labelled on every metricFree, instant

Built and reviewed by Sayed Hasan, founder of SEOs Hut · Updated 28 September 2026 · Free, no signup

core web vitals assessment failed

It means your real Chrome users failed at least one of LCP, INP or CLS at the 75th percentile over the last 28 days — not that your PageSpeed score is low. The two are different tests: the 0–100 score is a single throttled lab run that can't even measure INP, while the pass/fail assessment comes from Chrome UX Report field data. A green 90+ score and a failed field assessment can both be true on the same page at the same time.

The 0–100 score is not the Core Web Vitals result

They're commonly treated as one thing and they're not. The score is a single throttled lab simulation, weighted 30% on Total Blocking Time — a metric Google doesn't use to judge you at all — and it can't measure INP because Lighthouse loads pages with no real user input. The actual pass or fail Google applies is the 75th-percentile field assessment, built from 28 days of real Chrome users. A page can score 98 and still fail that assessment.

What each metric actually is

Every number this tool returns, and what it does and doesn't feed

Not everything here has an official Google cut-off. Here's what does, and what's diagnostic only.

LCP — Largest Contentful Paint

Good≤2.5s

Needs work2.5s–4s

Poor>4s

Both field and lab. Feeds the pass/fail assessment at the 75th percentile, and 25% of the 0–100 Lighthouse score.

INP — Interaction to Next Paint

Good≤200ms

Needs work200–500ms

Poor>500ms

Field-only. Became the stable Core Web Vital on 12 March 2024, replacing FID. Lighthouse cannot measure it — it never fires a real interaction — so it feeds the pass/fail assessment but not the 0–100 score at all.

CLS — Cumulative Layout Shift

Good≤0.1

Needs work0.1–0.25

Poor>0.25

Both field and lab. Feeds the pass/fail assessment and 25% of the 0–100 score.

TBT — Total Blocking Time

GoodNo official field threshold

Lab-only. Not a Core Web Vital at all — this is Lighthouse's stand-in for INP, since it can't fire real interactions. It's the single biggest slice of the 0–100 score, at 30%.

FCP — First Contentful Paint

GoodNo official field threshold

Lab metric. Feeds 10% of the 0–100 score. Useful as a diagnostic, not something Google assesses you on.

TTFB — Time to First Byte

GoodNo official CWV threshold

Not a Core Web Vital on its own, but it's the floor every other timing metric is built on — a slow TTFB pushes LCP up with it.

Page weight

GoodNo official threshold

Diagnostic only. Useful for spotting an oversized page; not something either the score or the assessment weighs directly.

What this run also checks

The same crawl grades three other things most people don't ask for

This tool is sold as a speed test. It's actually the full Lighthouse report — worth saying plainly, because the other three categories catch real problems a pure speed tool never would.

Accessibility

A full WCAG-aligned audit: colour contrast, missing labels, keyboard traps. Runs automatically alongside the speed numbers, at no extra step.

SEO

Lighthouse's own SEO checks — crawlability basics, mobile-friendliness signals, valid meta. A lighter pass than a dedicated audit, but free with every run.

Best Practices

Security and modern-standards checks: HTTPS, console errors, deprecated APIs. Easy to miss because it's rarely the reason anyone runs a speed test.

When the two tests disagree

Score says one thing, field data says another — which wins?

Does CrUX field data exist for this page at all?

No field data shown anywhere

Below the traffic threshold, or not publicly discoverableCrUX requires the page to return 200 after redirects with no noindex, and to clear an undisclosed minimum-visitor threshold. Low-traffic pages simply never get a score — that's not a failing state, it's an absence of data.

Field data exists but looks stale next to a fix you just shipped

You're ahead of the dataCrUX is a 28-day rolling average, refreshed daily around 04:00 UTC, and the API runs roughly two days behind. A fix from yesterday cannot appear yet — check back in over a week.

Lighthouse score is green, but the field assessment failed — which is real?

This exact situation

Trust the field assessmentThe 0–100 score is one throttled lab run weighted 30% on a metric Google doesn't assess you on. The field assessment comes from real Chrome users at the 75th percentile — that's what Google actually applies.

The score changed between two runs a minute apart

Two runs, same page, a minute apart, different numbers

Normal lab varianceNetwork and CPU throttling in a simulated run isn't perfectly reproducible. Run it three times and read the middle result, not the first one, before concluding anything changed on your site.

Who's actually being measured

Which browsers and devices feed the field data at all

CrUX isn't a general web-traffic sample — it's a specific, documented subset of Chrome users, opted in.

Source	Feeds CrUX field data?	Why
Chrome desktop, usage-stats reporting on	Yes	The baseline CrUX population
Chrome on Android, same opt-in	Yes	Included alongside desktop
Chrome with a sync passphrase set	No	Explicitly excluded in CrUX's documented methodology
Chrome on iOS	No	Runs a different rendering engine and contributes nothing to CrUX
Android WebView apps	No	Explicitly excluded
Other Chromium browsers, e.g. Microsoft Edge	No	Not part of the Chrome-only collection, whatever engine they share
A page returning non-200 after redirects	No	Excluded from CrUX entirely
A page with noindex, header or meta	NoSame exclusion that removes it from Google's search index	The page vanishes from Google's own field-performance dataset too

Scroll the table sideways to see every column.

Common misreads

Four ways the numbers get misunderstood

Reporting a single run as the score

What happens: Lab timing varies run to run under simulated throttling, so one run can overstate or understate the real picture.

Do this instead: Run it two or three times and take the middle result before drawing a conclusion or reporting a number to a client.

Chasing 100/100

What happens: Google states 100 is 'extremely challenging to achieve and not expected' — the gain from 99 to 100 needs roughly the same work as 90 to 94.

Do this instead: Aim for the green band, 90 and above. Treat 100 as a curiosity, not a target.

Optimising TBT while ignoring INP

What happens: TBT is 30% of the 0–100 score and easy to chase, but it's a lab proxy — improving it doesn't guarantee real users' INP moves with it.

Do this instead: Check the field INP number directly. It's the one Google actually assesses you on, and Lighthouse can't see it at all.

Assuming Edge or iOS users are represented in the field data

What happens: CrUX collects from opted-in Chrome desktop and Android only — Edge, iOS Chrome and WebView apps contribute nothing.

Do this instead: If a large share of your traffic is Edge or iOS, treat the field data as a partial picture of your real audience, not a complete one.

Where to look next

Speed problems are frequently caused elsewhere on the technical side — failed requests and dead assets inflate load time before a single pixel paints, and every extra hop in a chain is latency the visitor pays for directly. A full technical read sits behind the speed numbers too — check the rest of the page's crawlability. Once a fix ships, track whether it actually showed up in positions rather than assuming it will. And a page too JavaScript-heavy for this test to render cleanly is often unreachable for AI crawlers too, since most of them don't execute JavaScript — worth checking separately.

Questions

Core Web Vitals Checker FAQ

What is a good Core Web Vitals score?

There's no single 'score' for Core Web Vitals — the pass/fail assessment requires LCP at 2.5 seconds or under, INP at 200 milliseconds or under, and CLS at 0.1 or under, all measured at the 75th percentile of real visitors, and all three have to pass together. That's separate from the 0–100 Lighthouse number, which most people mean when they ask this.

How to pass Core Web Vitals assessment?

Get LCP, INP and CLS all into the 'good' band at the 75th percentile of your real Chrome traffic over a 28-day window — not in a single lab test. Since the assessment uses field data, a fix needs time to accumulate enough real visits before it shows as passing.

How fast should a page load?

There's no single official 'load time' target — Google's documented thresholds are per-metric: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1. Total page-load time isn't one of the three metrics the assessment actually checks.

What is a good page speed index?

Speed Index is a lab-only metric feeding 10% of the 0–100 Lighthouse Performance score. It has no official field threshold from Google, unlike LCP, INP and CLS, so treat it as a diagnostic detail rather than a pass/fail number.

Is there a free way to test my website speed?

Yes — this tool, and Google's own PageSpeed Insights, which it's built on. Both are free and return the same underlying Lighthouse and CrUX data; this version also labels every metric as lab or field so the two don't get conflated.

Why does my PageSpeed score change every time I run it?

Lighthouse simulates network and CPU throttling in a lab environment, and that simulation isn't perfectly reproducible run to run — server load and network conditions at the moment of the test both shift the result slightly. Run it three times and read the middle score rather than the first one you see.

Primary sources used on this page

web.dev: Core Web Vitals thresholds and the 75th-percentile pass rule — web.dev
web.dev: INP becomes a stable Core Web Vital, 12 March 2024 — web.dev
Chrome Developers: Lighthouse 10 Performance score weighting — developer.chrome.com
Chrome Developers: CrUX API, the 28-day rolling window and refresh schedule — developer.chrome.com
Chrome Developers: CrUX methodology — eligibility, exclusions and browser coverage — developer.chrome.com

Keep going

What usually sits behind a slow score

Speed problems rarely live only in the speed report. These check the technical causes and confirm whether a fix actually moved anything.

Website SEO Audit Broken Link Checker Redirect Checker Keyword Rank Checker AI Crawler Access Checker All 26 free tools →

Read the guide: How Important Is Page Speed for SEO? and How to Improve Website Speed: 18 Practical Steps. Want it handled for you? See our web design services.