What this page speed checker measures
This tool runs your page through Google PageSpeed Insights, the same engine behind Google's own speed report, and shows the parts that matter most. You get two kinds of data, and it helps to know the difference.
Field data comes from real Chrome users over the last 28 days (the Chrome UX Report). This is what Google uses for its Core Web Vitals assessment. Small or new sites often have no field data yet. When the page itself has too few visits, we show whole-site data if Google has it.
Lab data comes from a single Lighthouse test run on Google's servers, using a mid-range phone on a slower network (or a desktop if you pick Desktop). The performance score from 0 to 100 is based on lab data only. Lab results can vary by a few points from run to run, so test more than once before you draw conclusions.
Core Web Vitals and good scores
Google treats three metrics as Core Web Vitals. A page passes when the 75th percentile of real visits is "good" for all three:
Largest Contentful Paint (LCP) measures loading: how long until the main image or text block appears. Good is 2.5 s or less; poor is over 4.0 s.
Interaction to Next Paint (INP) measures responsiveness: how quickly the page reacts when someone taps or types. Good is 200 ms or less; poor is over 500 ms. INP replaced First Input Delay in March 2024. A lab test cannot click around like a person, so it shows Total Blocking Time (TBT) instead, which can help diagnose main-thread work but does not measure INP. Good TBT is under 200 ms.
Cumulative Layout Shift (CLS) measures visual stability: how much content jumps around while the page loads. Good is 0.1 or less; poor is over 0.25.
We also show First Contentful Paint (good under 1.8 s), Time to First Byte (good under 800 ms) and Speed Index, which help explain a slow LCP.
How to fix the most common problems
Slow LCP: make the main image smaller (WebP or AVIF, correct dimensions), do not lazy-load the hero image, add fetchpriority="high" to it, and cut render-blocking CSS and fonts. A slow server (high TTFB) delays everything, so caching or a CDN often helps most.
High TBT or INP: ship less JavaScript. Remove unused scripts, defer third-party tags such as chat widgets and extra analytics, and split large bundles so the main thread is free sooner.
High CLS: set width and height (or aspect-ratio) on images, videos and ad slots, reserve space for banners and embeds, and use font-display: swap with similar fallback fonts.
The "Top opportunities" list is sorted by estimated time saved, so start at the top. Savings are estimates from the lab run, not guarantees.
Does page speed affect Google rankings?
Yes, but modestly. Core Web Vitals are part of Google's page experience signals. A fast page will not outrank a much more relevant one, but good Core Web Vitals do not guarantee rankings. The bigger win is usually for visitors: faster pages keep more people on the page and lead to more sign-ups and sales.
If you run a tools or content site, test your most visited templates rather than every URL, because pages built from the same template usually share the same problems. Developers can tidy config files with our YAML to JSON converter or check redirect and rewrite rules in the regex tester.
Tips for reliable results
Test the exact public URL your visitors use, including https:// and the www or non-www version you redirect to. Test mobile first, because Google indexes the mobile version of your site. Results are cached for about 10 minutes. For independent measurements, wait for that cache to expire between tests and compare several runs, especially after a deploy, because caches may still be cold.
Pages behind a login, on localhost, or on a private network cannot be tested, because Google's servers have to load them over the public internet.