How to use the website speed checker
- 1Choose Mobile or Desktop (Google ranks with mobile data, so start there).
- 2Enter the page URL and press Test speed.
- 3Read Core Web Vitals from real users first: these are what visitors actually experienced.
- 4Then check the Lighthouse scores, Lab metrics and What would help most, and open the full report on pagespeed.web.dev for details.
Example: how field data is read
Chrome UX Report, 75th percentile for a page: LCP 2,840 ms (AVERAGE) · INP 160 ms (FAST) · CLS 4 (FAST) · overall AVERAGE
Largest Contentful Paint: 2.8 s · Needs improvement (good ≤ 2.5 s) Interaction to Next Paint: 160 ms · Good (good ≤ 200 ms) Cumulative Layout Shift: 0.04 · Good (good ≤ 0.1) Core Web Vitals: not passed
PageSpeed Insights reports CLS multiplied by 100, so 4 is a CLS of 0.04. A page passes only when all three metrics are good at the 75th percentile.
Lab data vs field data
Field data comes from the Chrome UX Report: anonymised timings from real Chrome users who visited the page (or the whole site, when the page has too little traffic) over the last 28 days. It's what Google uses for Core Web Vitals in Search. Lab data comes from one Lighthouse run on Google's servers, on an emulated mid-range phone with a throttled connection (or a desktop profile). Lab data is repeatable and explains why a page is slow; field data tells you whether real visitors noticed. When they disagree, trust the field data for the verdict and the lab data for the diagnosis.
Core Web Vitals: LCP, INP and CLS
| Metric | Measures | Good | Poor |
|---|---|---|---|
| LCP, Largest Contentful Paint | When the main content (largest image or text block) appears | ≤ 2.5 s | > 4 s |
| INP, Interaction to Next Paint | How quickly the page responds to taps, clicks and key presses | ≤ 200 ms | > 500 ms |
| CLS, Cumulative Layout Shift | How much content jumps around while loading | ≤ 0.1 | > 0.25 |
Each is judged at the 75th percentile of visits. INP replaced First Input Delay (FID) in March 2024. Lab tests can't measure INP because nobody interacts with the page; Total Blocking Time is the lab indicator for it.
What slows pages down
- Slow server response (TTFB): uncached pages, slow hosting or database queries; fix with caching and a CDN.
- Large images: the most common cause of slow LCP. Compress them with the image compressor, serve WebP or AVIF, size them for the screen, and don't lazy-load the main image.
- Render-blocking CSS and JavaScript: minify, defer non-critical scripts and inline critical CSS.
- Heavy JavaScript: long tasks block the main thread and hurt INP; remove unused code and third-party tags.
- Layout shifts: images, ads and embeds without reserved space, and late-loading web fonts.
Mobile vs desktop results
Mobile scores are almost always lower: the Lighthouse mobile profile emulates a mid-range phone with a slower CPU and a throttled network, while desktop uses a fast connection and full CPU. That's deliberate: many visitors use exactly such phones. Google uses mobile data for ranking with mobile-first indexing, so fix mobile first. Field data is reported separately for phones and desktops too.
Re-testing after changes
Lab scores vary a few points between runs because of network and server timing; run the test two or three times before deciding a change worked. Field data is a 28-day rolling window, so improvements take up to four weeks to show fully in the Core Web Vitals figures and in Search Console's Core Web Vitals report. Check the HTML weight with the page size checker and phone rendering with the mobile-friendly test.
What happens to the address I enter?
This tool sends the address you enter to Google PageSpeed Insights to run a Lighthouse test and read Chrome UX Report data. Their privacy policy applies to that request. We don't store the results.