Page Speed Test & Core Web Vitals Checker

https://example.com/product/blue-widget

This checker reads Google's real-user Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. for a page and gives you a one-sentence verdict plus a prioritized fix list. For whole-site field-data trends over time, use the Core Web Vitals History & Competitor Comparison; to see what a bot renders versus what a user sees, use the Render Gap Checker.

What the results mean

The verdict badge summarises the whole page in one word:

• Passes (green) — every Core Web Vital is "good" on every device that had data.
• Not passing (red) — at least one Core Web Vital is "needs improvement" or "poor". The headline names the single worst-performing metric, on the worst device.
• Partial data (amber) — the metrics that had data all passed, but at least one Core Web Vital was missing, so the pass can't be certified outright.
• No field data (amber) — Chrome has no field measurements for this page or origin, so only simulated lab numbers are shown.

Each metric value is colour-coded against the official thresholds:

Core Web Vitals thresholds at the 75th percentile

Rating	LCP	INP	CLS
Good	≤ 2.5 s	≤ 200 ms	≤ 0.1
Needs improvement	2.5–4.0 s	200–500 ms	0.1–0.25
Poor	> 4.0 s	> 500 ms	> 0.25

Source: Google Web Vitals · Updated: 2026-07-12

• Good (green) — LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1.
• Needs improvement (amber) — between the good and poor lines.
• Poor (red) — LCP > 4 s, INP > 500 ms, CLS > 0.25.
• No data (grey) — no sample for that metric (INP from a lab audit reads "no lab INP").

For metric-specific causes and fixes, read the guides to Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift.

The source tag on each card is deliberately loud, because mistaking lab numbers for real-user data is the most common CWV error:

• field · this URL — real-user data for the exact page (best case).
• field · whole site — origin-level real-user data, used when the specific URL has no sample.
• lab · simulated — one Lighthouse run with simulated throttling; numbers vary between runs, cannot certify a pass, and do not represent a target market when the upstream provider supplies no test location.

How it works

Enter a URL and the tool calls a small server endpoint that queries the Chrome UX Report for both mobile and desktop. CrUX is Google's 28-day rolling dataset of real Chrome users — the same field data behind the page-experience signal. If the specific URL has no sample, the endpoint retries at origin level; if that is also empty, it runs a Lighthouse lab audit for at least some diagnostics.

The pass verdict logic, thresholds, and fix ranking live in shared, testable code. Ratings use the exact official cut-offs; the verdict picks the binding constraint by scoring how far each underperforming metric sits past its "good" line and breaking ties toward mobile. The fix engine cross-references the worst-performing metric with the Lighthouse audits that actually fired on the page (render-blocking resources, slow server response, unoptimized images, heavy third-party JS, layout-shift elements, and more) so the advice is specific — with a per-metric fallback so every underperforming metric always gets at least one concrete next step.

Features

• Verdict-first: one plain-English sentence naming the single worst-performing metric on the worst device, instead of a wall of numbers.
• Real-user field data first (CrUX), with automatic fallback to origin field data, then to a simulated Lighthouse lab audit — each source clearly labelled per card.
• Mobile and desktop shown side by side, with mobile flagged as the device Google ranks on.
• Prioritized, diagnostic fix list built from the Lighthouse audits that actually fired, not generic tips.
• Optional fresh lab audit on pages that already have field data, for extra diagnostics.
• Bulk mode: an origin scorecard for up to 5 domains (mobile field data) with CSV export.
• Nothing you check is stored; repeat checks within 24 hours are served from cache.

Limitations

Field data needs traffic: low-traffic or brand-new pages get no CrUX sample, so you'll see origin data or lab numbers instead. Lab audits use simulated throttling; this public check reports one run, so it varies between runs and cannot measure INP from real interactions. Paid/admin audits can use a three-run median workflow when repeatability is needed. PSI does not provide a regional test location, so its lab result must not be treated as target-market performance; use a regional provider when geography matters. Field data lags reality by up to 28 days, so a fix shipped yesterday will not immediately appear in the rolling window.

Frequently asked questions

What are the Core Web Vitals thresholds?

A page passes when its 75th-percentile score is "good" for all three metrics: Largest Contentful Paint (LCP) at 2.5 seconds or faster, Interaction to Next Paint (INP) at 200 milliseconds or faster, and Cumulative Layout Shift (CLS) at 0.1 or lower. LCP over 4 seconds, INP over 500 milliseconds, or CLS over 0.25 is "poor"; anything between the two thresholds is "needs improvement". The tool uses these exact official cut-offs.

Why do my Core Web Vitals scores differ from PageSpeed Insights?

They should match when both are reading the same source. This tool shows Chrome UX Report (CrUX) field data first — the same real-user dataset Search uses — and only falls back to a Lighthouse lab audit when a page has no field data. Lab numbers use simulated throttling and vary between runs, so a lab score will not line up with a field score. If your PageSpeed number is a lab score and ours is field data, or vice versa, that is the difference.

Why does the checker say "no field data" for my URL?

CrUX only reports a URL once it has enough Chrome traffic to form a statistically stable sample over the trailing 28 days. Low-traffic or brand-new pages never cross that bar. When that happens the tool falls back to origin-level field data (the whole site) or a simulated Lighthouse lab audit, and it labels which source each card is using so you never mistake lab numbers for real-user data.

Can this tool measure INP?

It can report INP from field data, because INP is measured from real user interactions. It cannot produce an INP number from a lab audit — Lighthouse has no real users to interact with the page, so a lab-only result shows "no lab INP" for that metric. If you need an INP figure and the page has no field data, you need real traffic (or the Chrome DevTools INP tooling on your own interactions).

Which device does Google use for ranking — mobile or desktop?

Google evaluates the page-experience signal on mobile, so the tool marks the mobile card "what Google ranks on" and, when a page does not pass on both devices, names the mobile metric as the binding constraint. Desktop scores are shown for context but do not decide the mobile ranking assessment.