A page speed checker that explains the PageSpeed Insights report
This page speed checker runs Google PageSpeed Insights on any public page and turns the report into something you can act on: the Lighthouse performance score, the Core Web Vitals that real Chrome users experienced — Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS) — the lab metrics, and the biggest fixes in plain words. Test mobile, desktop or both, or put two pages side by side.
The test runs on Google’s servers. Your browser asks the PageSpeed Insights API only when you press Run speed test, so the numbers match Google’s own report. Without an API key the free shared quota is often used up, so the tool explains how to add your own free key — and if a test can’t run, it says why and links to the same test on the PageSpeed Insights website.
How to test your page speed
- Enter the address of a public page — a home page, product page or article.
- Choose Mobile, Desktop or Both; tick Compare with a second page to test a competitor or another version of your page.
- Paste your PageSpeed Insights API key (recommended) and tick Remember the key if you want it kept in this browser.
- Press Run speed test and wait 15–40 seconds while Google loads the page.
- Read What real visitors experience first, then the lab test and the Biggest opportunities, sorted by the time each could save.
Page Speed Checker features
Field data first
The Chrome UX Report’s 75th-percentile LCP, INP, CLS, FCP and TTFB, each rated with the official thresholds, with the share of good, average and poor visits and the Core Web Vitals verdict.
Lab metrics explained
First Contentful Paint, Largest Contentful Paint, Total Blocking Time, Cumulative Layout Shift and Speed Index from Lighthouse, each with a one-line meaning.
Fixes in plain words
Lighthouse’s insights and diagnostics are sorted by estimated savings and rewritten in everyday language: what is slow and what to change.
Mobile and desktop
Run one device or both and switch between them; a screenshot shows how the page looked when the test finished.
Two pages side by side
Compare scores and every metric for two URLs, with the better value marked on each row.
Clear error messages
Quota limits, timeouts, pages that return 404, blank pages and invalid keys are explained, with a link to run the test on the PageSpeed Insights website.
Core Web Vitals thresholds
Each value is the 75th percentile of real visits over the last 28 days: three visits in four were at least that fast. A page passes the Core Web Vitals assessment when LCP, INP and CLS are all good; with too little INP data, LCP and CLS decide. INP replaced First Input Delay as a Core Web Vital in March 2024.
| Metric | Good | Needs improvement | Poor | Measures |
|---|---|---|---|---|
| Largest Contentful Paint (LCP) | ≤ 2.5 s | 2.5–4 s | > 4 s | Loading: when the main content appears |
| Interaction to Next Paint (INP) | ≤ 200 ms | 200–500 ms | > 500 ms | Response to taps, clicks and keys |
| Cumulative Layout Shift (CLS) | ≤ 0.1 | 0.1–0.25 | > 0.25 | Visual stability |
| First Contentful Paint (FCP) | ≤ 1.8 s | 1.8–3 s | > 3 s | First text or image |
| Time to First Byte (TTFB) | ≤ 0.8 s | 0.8–1.8 s | > 1.8 s | Server and network response |
Worked example: reading the built-in report
The example bakery page scores 58 on mobile. Its field data shows why the Core Web Vitals assessment fails: LCP is 2.9 seconds, just over the 2.5-second line, and CLS is 0.12, over 0.1, while INP at 160 ms is good. In the lab, LCP is 4.6 s and Total Blocking Time 380 ms.
The top opportunity is render-blocking requests, worth about 1.15 seconds: inline the CSS for the top of the page and defer scripts. Next come image delivery — about 412 KiB to save, where the Image Compressor and WebP help — and cache lifetimes. Fix them, deploy and test again; field data takes up to 28 days to catch up.
Lab score versus real users
- The score is a lab result. Lighthouse loads the page once on a simulated mid-range phone with a throttled connection (or as a desktop) and weights five metrics: Total Blocking Time 30%, LCP 25%, CLS 25%, FCP 10% and Speed Index 10%. 90–100 is good, 50–89 needs improvement and under 50 is poor.
- Scores vary between runs. Network and server timing differ each time, so a few points either way is normal.
- Field data is what counts for search. Google says its ranking systems use Core Web Vitals, as one signal among many; relevant content still matters most.
- New or small sites may have no field data, because the Chrome UX Report only includes pages and sites with enough Chrome visitors. Rely on the lab test until then.
- For layout problems on phones, use the Mobile-Friendly Checker; for redirects and server responses, the HTTP Status Checker.
Page Speed Checker FAQ
How do I check my website’s page speed?
Enter the page address in this page speed checker and press Run speed test. Google PageSpeed Insights loads the page and returns the performance score, Core Web Vitals and fixes, explained here in plain words.
What is a good PageSpeed Insights score?
90 to 100 is good, 50 to 89 needs improvement and below 50 is poor. Passing the Core Web Vitals assessment with real-user data matters more than a perfect lab score.
Why does the test say “quota exceeded”?
Requests without an API key share a small free quota among everyone using the PageSpeed Insights API, so it is often used up. A free key from the Google Cloud console gives you your own quota, and it is sent only to Google.
Why is my mobile score lower than desktop?
The mobile test simulates a mid-range phone with a slower processor on a throttled connection, so scripts and large images cost more. Google indexes the mobile version of pages, so mobile is the score to improve first.
Why is there no real-user data for my page?
The Chrome UX Report covers only pages and sites with enough Chrome visitors who share usage statistics. New or low-traffic pages show lab data only; data for the whole site often appears first.
Is the page I test made public?
The address is sent to Google’s PageSpeed Insights service, which loads the page as a visitor would. Nothing goes to this site’s server, and only public pages can be tested.