Find the mobile metric preventing a page from passing
Start with the plain-language verdict, then identify whether loading speed, interaction responsiveness, or visual stability is the binding problem.
Page Speed Test & Core Web Vitals Checker
Free, no signup. Core Web Vitals reports are usually a wall of numbers before they tell you anything useful. This leads with one sentence: whether the page passes, and the single thing to fix first — real Chrome user data when it exists, a Lighthouse lab audit when it doesn't.
Sample report
Say you check a product page:
https://example.com/product/blue-widget…and Chrome has field data showing a slow mobile load. The tool returns:
Illustrative example — real results need a live CrUX/PageSpeed Insights lookup this static page can't make; the good/needs-improvement/poor bands shown match this tool's actual LCP/INP/CLS thresholds (2.5s/4s, 200ms/500ms, 0.1/0.25)
Not passing
This page does not pass Core Web Vitals because of LCP (loading) on mobile.
https://example.com/product/blue-widget
Mobile — what Google ranks on field · this URL
LCP 4.3 s
INP 158 ms
CLS 0.06
Desktop field · this URL
LCP 1.9 s
INP 120 ms
CLS 0.03
What to fix, in order
- Optimize the largest imageLCP
Your largest element is likely an unoptimized image. Serve it in a modern format (AVIF/WebP), size it to the space it actually fills, and add fetchpriority="high" so the browser loads it first.
- Speed up server response (TTFB)LCP
Your server is slow to send the first byte, which caps how fast LCP can ever be. Add full-page or edge caching, and check for slow database queries or origin round-trips.
- Desktop passes on all three metrics, but mobile LCP sits at 4.3 s — past the 4 s "poor" line — so the page does not pass overall. See what the color bands mean ↓.
- Google evaluates page experience on mobile, so the verdict names the mobile LCP result specifically as the one thing to fix first, even though desktop is clean.
- The fix list is ordered, not just listed — image optimization and server response time both move LCP, so both appear ahead of any INP/CLS advice, which this page doesn't need here.
- Confirm the fix actually landed on mobile specifically with the Mobile-Friendly Tester.
How to use it
- Paste a full page URL into the Single URL box (the scheme helps —
https://example.com/page). - Press Check vitals. The tool pulls field data for that exact URL first; if Chrome has none, it falls back to whole-site (origin) field data, then to a simulated Lighthouse lab audit — each card is labelled with the source it used.
- Read the verdict banner first: one sentence naming whether the page passes and, if not, the single worst metric holding it back.
- Scan the mobile and desktop cards side by side, then work down the numbered What to fix, in order list.
- Need diagnostics on a page that already has field data? Click Run a fresh lab audit instead for Lighthouse-driven fix detail. To compare several sites at once, switch to Bulk domains (up to 5) for an origin scorecard with CSV export.
+ saves the current site or page. Use ☆ beside any saved site, page, or list to favorite it. Recent check history appears below.
Create a named list
Target filled from your local choices.
Site passport Local context for this saved site
Local data
Saved targets, named lists, and recent check summaries remain only in this browser.
Lab methodology and provenance
Geography: PSI does not provide a test location. A non-regional lab result is diagnostic, not evidence of performance for local users or a target market. Use a regional provider when geography matters.
Lab vs. field comparison
Field data describes real Chrome visits over 28 days; lab data is one simulated run. Use the lab trace to investigate, then use field data to judge the real-user outcome.
What to fix, in order
Elements Lighthouse singled out
Runs Lighthouse on mobile + desktop — takes ~30 seconds, numbers are simulated and vary between runs.
Compare a later check
Download this result as a private JSON baseline, then import it after another check to compare the verdict, data source, and metric changes.
Rate this tool
Origin scorecard (mobile field data)
| Origin | Verdict | Worst metric | LCP | INP | CLS |
|---|
Field data is Google's Chrome UX Report — the same 28-day real-user dataset Search uses for the page-experience signal; it updates daily, so repeat checks within 24 hours are served from cache. Lab numbers come from Lighthouse with simulated throttling: expect them to differ from field data and to vary between runs. Lab audits can't measure INP (it needs real users).
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:
| 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 |
- 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 (LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good.) at 2.5 seconds or faster, Interaction to Next Paint (INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good.) at 200 milliseconds or faster, and Cumulative Layout Shift (CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.) 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 (CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program.) field data first — the same real-user dataset Search uses — and only falls back to a LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. 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.
Feature requests for Cwv Checker
Upvote what you want most. New ideas can be submitted from the floating Feedback menu; requests appear here once approved, and the most-wanted rise to the top.
You won't be emailed about that request anymore.
Loading…
➕ Request a feature
New requests are reviewed before they appear here.
Where this tool helps
Common use cases
Keep real-user field data separate from a lab test
Use the visible source labels to distinguish an exact-page Chrome sample, a whole-site fallback, and one simulated Lighthouse run.
Turn a failed result into an ordered fix list
Prioritize the diagnostics tied to the failing Core Web Vital instead of chasing an overall performance score or unrelated recommendations.
Compare mobile and desktop without mixing their roles
Review both device experiences side by side while keeping the mobile field result central to the page-experience assessment.
Build a five-domain mobile scorecard
Compare origin-level field results in bulk, group failing sites by their worst metric, and export the bounded scorecard for follow-up work.
Watch the full workflow
Page Speed Test & Core Web Vitals Checker walkthrough
Read the transcript
Page Speed & Core Web Vitals
This beginner walkthrough follows the plain-language Page Speed entry point into the full Core Web Vitals checker. We will cover the most useful use cases, the safe web-address handoff, one complete real-user field-data example, a separate simulated lab audit, prioritized fixes, baseline comparison, a five-domain scorecard, limitations, and the right next tool. Every result shown is a fixed walkthrough fixture, not a live claim about a website.
Step 1
Page Speed and Core Web Vitals Checker starts with the question most people actually have: do real visitors get a good experience, and what should I fix first? This entry page does not run a second competing test. It validates one complete public web address and sends it into the canonical checker, where the same result engine handles field data, lab diagnostics, mobile, desktop, and bulk comparison.
Step 2
Use this entry point when you want a page-level speed check without deciding the data source in advance, when you need to explain why a Lighthouse score differs from the field verdict, or when a new page may have too little traffic for an exact-page sample. It also helps you hand a web address into the checker safely and choose whether the next question needs long-term trends, a mobile-layout test, or a rendered-page comparison.
Step 3
Field data summarizes what real Chrome visitors experienced at the seventy-fifth percentile over a rolling twenty-eight-day window. A lab test is one simulated Lighthouse run under controlled conditions. The field result is the Core Web Vitals evidence. The lab result is a diagnostic clue that can vary between runs and cannot reproduce real-user interactions. This distinction prevents a good-looking performance score from being mistaken for a passing field verdict.
Step 4
Paste a complete public page address, including H T T P S, then choose “Test page speed”. The three visible steps show the lookup order: exact-page field data, whole-site field data, and finally a Lighthouse fallback. The gateway itself does not submit or store the address. It only preserves the value for the checker, and the checker still waits for an explicit click before making a request.
Step 5
Choose “Test page speed”. The browser opens the canonical checker with the fixed reserved-domain address already filled in. Notice that no result appears and no performance request starts automatically. This is a handoff, not a hidden run. The single-address tab, bulk tab, input, source order, privacy statement, and “Check vitals” action are now in one place.
Step 6
The full checker is designed to find the mobile metric preventing a page from passing, keep exact-page field data separate from whole-site and lab fallbacks, turn a failed result into an ordered fix list, compare mobile and desktop without mixing their roles, and build a five-domain mobile scorecard. Those jobs share one important habit: read the verdict and its source before interpreting any individual number.
Step 7
The workflow is simple. Paste the full address. Choose “Check vitals”. Read the one-sentence verdict first. Compare mobile and desktop and confirm the source label on each card. Then work down “What to fix, in order”. If the page already has field data, run a fresh lab audit for deeper diagnostics. Use bulk mode only when you need a bounded origin-level scorecard rather than one page diagnosis.
Step 8
Choose “Check vitals”. The fixed response opens a failing field result for a reserved example domain. The capture blocks every external response, so these values are deterministic training data, not a live observation. The status completes, the verdict appears, and the page keeps the exact address with the result so another person can see what was tested.
Step 9
The red badge says “Not passing”. The sentence names the reason: Largest Contentful Paint, the loading metric, is poor on mobile. This is the binding metric, meaning it is the clearest thing holding the result back. Starting here keeps a beginner from chasing every number or treating the overall page as vaguely slow.
Step 10
Both cards are labelled “field — this URL”, so they describe real-user samples for the exact page. Mobile Largest Contentful Paint is 4.3 seconds and poor. Interaction to Next Paint, the responsiveness metric, is 180 milliseconds and good. Cumulative Layout Shift, the visual-stability metric, is 0.06 and good. Desktop passes all three. The supporting paint and server-response numbers add context, but they do not replace the three core metrics.
Step 11
The ordered list stays focused on loading. First, resize and compress the actual largest image, use a modern format, and preload it only if it is truly the main visible element. Second, investigate page caching, edge caching, application work, and origin round trips that delay the first server response. The point is not to apply generic speed advice. Confirm the element and bottleneck, then change the smallest thing that moves the failing metric.
Step 12
“Compare a later check” can download this result as a private J S O N baseline. After a future run, import that file to compare the verdict, data source, and metric changes. A baseline is evidence of what the tool returned at one time; it is not proof that a release caused the change. Keep the release date and implementation notes beside it.
Step 13
Choose “Run a fresh lab audit instead”. The fixed Lighthouse response replaces the visible cards and keeps the earlier field result in memory for comparison. The new headline says lab estimates are available but only Chrome field data can certify Core Web Vitals. That wording is intentional: the lab helps diagnose the page without pretending one simulation is the real-user verdict.
Step 14
The source labels now say “lab — simulated”. Mobile receives a Lighthouse performance score of 63, desktop 92. The lab estimates mobile loading at 3.1 seconds and flags a small layout-shift issue, but it shows no lab interaction number because simulated loading cannot reproduce real-user interactions. These numbers suggest where to inspect. They do not overrule the poor 4.3-second mobile field result.
Step 15
The comparison calls out three disagreements. Mobile loading improves from poor in the field to needs improvement in the lab. Visual stability moves from good in the field to needs improvement in the lab. The initial server response improves to good in the lab. Differences are normal because the populations, time windows, devices, and conditions differ. Use the lab trace to investigate and field data to judge the real-user outcome.
Step 16
The lab response identifies the example hero image as the likely largest element and a late-loaded product-rating widget as a layout-shift candidate. Those concrete elements make the advice testable. The provenance section records PageSpeed Insights, Lighthouse version, exact and final address, timestamp, device profile, throttling method, run count, and the fact that the provider does not supply a regional test location. Keep those boundaries with any engineering handoff.
Step 17
Switch to “Bulk domains” and enter up to five domains, one per line. Bulk mode checks mobile field data at the whole-site origin level. It does not run five Lighthouse audits, and origin data is less specific than an exact-page sample. Use it for a quick portfolio or competitor triage view, then open the single-address checker when a particular page needs diagnosis.
Step 18
Choose “Build scorecard”. The fixed response groups two origins under failing mobile loading and one under failing mobile interaction responsiveness. The table keeps one passing origin, three not-passing origins, and one honest “no field data” row. Missing data is not a pass or a failure. It simply means this field source cannot evaluate that origin.
Step 19
The reason groups turn the scorecard into a work queue: loading issues together, responsiveness issues together. Each row shows the origin, verdict, worst metric, and the three core values when available. “Export CSV” creates a spreadsheet-friendly handoff. Preserve that it is mobile origin-level field data, along with the check date, rather than presenting it as a page-by-page audit.
Step 20
Use Core Web Vitals History and Competitor Comparison when you need long-term field trends. Use Mobile-Friendly Tester when the remaining question is viewport, sizing, or responsive layout. Use Render Gap when scripts may change content, links, canonicals, or indexability after the initial document loads. The right follow-up tool depends on the evidence gap, not on which score looks most dramatic.
Step 21
The main features are a verdict-first result, exact-page field data with clearly labelled fallbacks, side-by-side devices, prioritized diagnostics, an optional fresh lab run, private baselines, and a five-domain export. The limits matter just as much. Low-traffic pages may have no exact sample. One public lab run varies and has no real-user interaction measurement or regional test location. Field data can lag a release by up to twenty-eight days. Always keep the source, scope, device, and date with the number.
Read the source. Fix the binding metric. Then measure again.
Keep the page address, device, source label, measurement window, metric values, release date, and fix together. Use a lab trace to check whether the implementation improved, then watch the rolling field data for the real-user outcome. A performance score is not the field verdict, and speed is not a shortcut to rankings. Improve the experience, preserve the evidence, and choose the follow-up test that answers the next question.
Common issues & how to fix them
- Error LCP is poor Fix: Cut LCP below 2.5 seconds by optimizing the measured LCP element and its critical delivery path, then verify with fresh field data.
- Warning LCP needs improvement Fix: Bring LCP below 2.5 seconds by prioritizing the measured LCP element and removing delay from its delivery path.
- Error INP is poor Fix: Cut INP below 200 ms by shortening the longest interaction tasks and reducing JavaScript work on the main thread.
- Warning INP needs improvement Fix: Bring INP below 200 ms by breaking up long interaction handlers and yielding main-thread work.
- Error CLS is poor Fix: Cut CLS below 0.1 by reserving space for shifting elements and preventing late font or content swaps.
- Warning CLS needs improvement Fix: Bring CLS below 0.1 by adding stable dimensions and placeholders for elements that move after first paint.
- Warning Render-blocking resources may delay LCP Fix: Inline critical CSS and defer non-critical stylesheets or scripts that block the LCP resource from rendering.
- Warning Server response may delay LCP Fix: Reduce initial server response time with caching, faster backend work, and a CDN near users before optimizing the LCP asset.
- Warning Image delivery may delay LCP Fix: Resize and compress the LCP image, serve a modern format with srcset, and preload it when discovery is late.
- Information Critical origin lacks preconnect Fix: Add preconnect only for the critical third-party origin that serves the LCP resource, including crossorigin when required.
- Warning Third-party code contributes to INP Fix: Defer or delay non-critical tag managers, chat, analytics, and testing scripts until after the first interaction, and remove unused vendors.
- Warning Main-thread work contributes to INP Fix: Break long main-thread tasks into smaller chunks, move heavy computation to a worker, and minimize synchronous layout work.
- Warning Unused JavaScript contributes to INP Fix: Code-split by route and component so the page downloads, parses, and executes only JavaScript needed for the current view.
- Warning Layout-shift elements contribute to CLS Fix: Give the reported images, embeds, ads, and injected regions explicit dimensions or reserved placeholders before they load.
- Warning Font loading contributes to CLS Fix: Preload critical fonts, use metric-compatible fallbacks, and choose font-display behavior that avoids a late layout-changing swap.
- Warning Lab and field performance disagree Fix: Use the Lighthouse trace to diagnose the simulated-run bottleneck, then monitor the matching CrUX metric before claiming or closing a real-user regression.