Free tool Page speed test for any website: real-user Core Web Vitals and a Lighthouse run
Enter a URL. Google’s PageSpeed Insights API returns two different things, and this page keeps them apart: what real Chrome visitors experienced over the last 28 days, and one simulated load by Lighthouse with the fixes that would save the most time.
- Field and lab data, side by side
- Mobile and desktop
- Request goes from your browser to Google
Test a page
Pick mobile or desktop and press the button. Switching device after a test runs the other one for the same URL.
What is sent, and where
- Only when you press the button: the page URL, mobile or desktop, the report language and the API key go from your browser straight to Google (
www.googleapis.com). TapCub does not see, relay or store them. - Google's servers then load that page the way a visitor would and return the report. Google's privacy policy applies to that request.
- A key you type stays on this page. It is saved in this browser (
localStorage) only if you tick “Remember”; untick to delete it. - Networks or extensions that block www.googleapis.com — some company networks, some ad blockers, and mainland China — make the test fail with a network error.
No test run yet
Enter a URL and press the button. Real-user data and the lab test appear here. Meanwhile, these are the thresholds Google uses for real-user data:
| Metric (75th percentile) | Good | Needs improvement | Poor |
|---|---|---|---|
| Largest Contentful Paint (LCP) | ≤ 2.5 s | 2.5 s – 4.0 s | > 4.0 s |
| Interaction to Next Paint (INP) | ≤ 200 ms | 200 ms – 500 ms | > 500 ms |
| Cumulative Layout Shift (CLS) | ≤ 0.10 | 0.10 – 0.25 | > 0.25 |
| First Contentful Paint (FCP) · not a Core Web Vital | ≤ 1.8 s | 1.8 s – 3.0 s | > 3.0 s |
| Time to First Byte (TTFB) · not a Core Web Vital | ≤ 800 ms | 800 ms – 1.8 s | > 1.8 s |
Source: PageSpeed Insights documentation (“About PageSpeed Insights”) and web.dev, checked 2026-11-11.
Share these inputs: the values go after the # in the link, so they never reach a server.
https://tapcub.com/tools/pagespeed-checker
Version v1.0Updated Update history
Four parts, read in this order
Start with what real visitors experienced, then use the lab run to find out why.
Core Web Vitals assessment
Passed means the 75th percentile of LCP, INP and CLS are all “good” for real Chrome users over 28 days. If INP has too little data, LCP and CLS decide; without LCP or CLS there is no assessment.
Field metrics and the colour bar
The big number is the 75th percentile; the bar shows what share of visits were good, needed improvement or were poor. A page can pass at p75 and still give one visit in five a poor experience.
Performance score
A 0–100 summary of one Lighthouse lab run, weighted from five metrics. It is useful for before / after comparisons on the same device setting, not as a grade of what users feel.
What to fix first
Failed insights and diagnostics with Lighthouse’s estimate of time saved. Start with items that save LCP or FCP time if LCP is your weak field metric, and with blocking-time items if INP is.
Field data comes from Chrome users who opted in to sharing usage statistics, so it covers Chrome only and needs enough traffic. A site whose visitors mostly use other browsers may have little or no field data.
From one test to a faster page
Test the pages that bring visitors and conversions, not only the home page.
-
1
Test a key page on mobile
Most traffic is mobile and Google indexes the mobile version, so start there. Then switch to desktop.
-
2
Read field data first
If real users already get “good” at p75, a mediocre lab score is less urgent. If they do not, find which metric fails.
-
3
Fix the top items, then retest
Work through “What to fix first”, deploy, and run the lab test a few times. Field data updates over the next 28 days.
-
4
Watch every page continuously
A one-off test samples one URL. Real-user monitoring in your analytics shows all pages and every release.
Thresholds and weights used on this page
Field metrics are judged with Google’s thresholds at the 75th percentile. The lab score is Lighthouse’s weighted average of five metric scores.
- Field: good if p75 ≤ the “good” limit, poor if above the “poor” limit, otherwise needs improvement (PageSpeed Insights documentation)
- Core Web Vitals = LCP, INP and CLS; FCP and TTFB are shown as supporting metrics
- Lab score bands: 90–100 good, 50–89 needs improvement, 0–49 poor; each lab metric is coloured by its own Lighthouse score the same way
- INP needs real interactions, so it exists only in field data; the lab run shows Total Blocking Time instead
| Metric | Field (p75) | Lab | Good | Poor | Weight in score |
|---|---|---|---|---|---|
| LCP | Yes | Yes | ≤ 2.5 s | > 4.0 s | 25% |
| INP | Yes | — | ≤ 200 ms | > 500 ms | — |
| CLS | Yes | Yes | ≤ 0.1 | > 0.25 | 25% |
| FCP | Yes | Yes | ≤ 1.8 s | > 3.0 s | 10% |
| TTFB | Yes | — | ≤ 0.8 s | > 1.8 s | — |
| TBT | — | Yes | Lighthouse curve | Lighthouse curve | 30% |
| Speed Index | — | Yes | Lighthouse curve | Lighthouse curve | 10% |
Reading one mobile result
Made-up numbers for a product page, read the way this tool presents them.
| Part | Value | Reading |
|---|---|---|
| LCP, field p75 | 2.9 s | Needs improvement (above 2.5 s); 68% of visits were good |
| INP, field p75 | 180 ms | Good (≤ 200 ms) |
| CLS, field p75 | 0.12 | Needs improvement (above 0.1) |
| Core Web Vitals | Failed | LCP and CLS are not good, even though INP is |
| Lab performance score | 58 | Needs improvement; compare after fixes on the same device setting |
| Top fix | Render-blocking requests, LCP −0.9 s | Inline critical CSS, defer the rest, then retest |
In this example the order of work is: LCP (render-blocking CSS, hero image size), then CLS (reserve space for images and banners). INP is already fine.
Where page speed tests mislead
Four habits that waste time.
Chasing 100
The lab score is one simulated load. Moving from 92 to 100 rarely changes what users feel; failing field metrics do.
Trusting a single run
Lab results vary between runs with server load and network. Run three times and compare the middle result.
Mixing lab and field
A good lab LCP with a poor field LCP usually means real devices, networks or logged-in pages are slower than the test. Fix for the field number.
Testing only the home page
Product, article and checkout pages use different templates and are often slower. Test the pages that earn traffic.
Web Vitals from your own visitors, on every page
PageSpeed Insights samples one URL from Google’s side. The TapCub snippet measures your real visitors on every page.
Core Web Vitals at p75 by page
LCP, INP and CLS from real visits, plus FCP and TTFB, collected by the same analytics snippet, split by device type.
Learn moreSlowest pages first
Pages and templates ranked by how slow they are, so you know which URL to test and fix next.
Learn moreErrors next to speed
JavaScript, resource and API errors with affected sessions, in the same report.
Learn morePage speed test FAQ
Still have a question?
Chat with the team behind TapCub — we usually reply within a few hours on business days.
What is a good page speed score?
Lighthouse treats 90–100 as good, 50–89 as needs improvement and 0–49 as poor. But the score comes from one simulated load. What matters more is whether real users pass Core Web Vitals: LCP ≤ 2.5 s, INP ≤ 200 ms and CLS ≤ 0.1 at the 75th percentile.
Why are field data and lab data different?
Field data is 28 days of real Chrome visits on all kinds of phones and networks. Lab data is one load on one emulated device with a fixed network from Google’s servers. They answer different questions: field data says how users fare, lab data helps you find why.
Why does my score change every time I test?
Lab runs vary with Google’s server load, your server’s response time, third-party scripts and ads. Differences of a few points are normal. Run the test several times and compare the middle result.
Why is there no real-user data for my page?
CrUX only includes pages and sites with enough eligible Chrome traffic in the last 28 days. When a URL has too little, Google falls back to the whole site; when the site has too little, there is none. Google has also said it plans to stop including CrUX data in this API; on 2026-11-11 it was still returned.
Do Core Web Vitals affect Google rankings?
Google’s page experience documentation says “Core Web Vitals are used by our ranking systems”. They are one signal among many; relevant, helpful content still matters more. Your own analytics can show whether slow pages also lose visitors on your site.
Why do I need an API key?
This page calls Google’s PageSpeed Insights API directly from your browser. Google no longer gives keyless requests any quota, so each request needs a key. The key is free with a Google account and only identifies whose daily quota is used.
Is this the same as Google PageSpeed Insights?
It uses the same API and the same Lighthouse engine, so the numbers match a run at the same moment. This page keeps field and lab data apart, explains the thresholds and sorts fixes by time saved. The official interface is pagespeed.web.dev.
Should I test mobile or desktop?
Both, starting with mobile. Google completed its move to mobile-first indexing in 2023, so the mobile version is what it crawls, and mobile tests use a slower emulated device and network.
Update history
New features, fixes and data refreshes for this tool, newest first.
-
· v1.0
LaunchedFirst release.
Data this tool relies on
- PageSpeed Insights / Lighthouse audits — checked 2026-11-11, reviewed every 6 months (next review by 2027-05-11)
Missing something or found an error? Tell us — requests that come up often go into the next update. All tool updates
Stop sampling one URL at a time
Measure Core Web Vitals on every page from your real visitors, and see which pages are slowest.