Website performance checker: Core Web Vitals, server response and render-blocking files
See how fast real visitors find your page from Chrome UX Report data, how quickly the server answers, and which scripts, stylesheets, fonts and images hold up the first paint.
What is checked
| Check | Measured from | Rule |
|---|---|---|
LCP, INP and CLS | Chrome UX Report | Real Chrome users on phones, 75th percentile. Good is LCP up to 2.5 s, INP up to 200 ms and CLS up to 0.1. |
Time to first byte | Server response | One request as a regular browser, redirects included. Up to 800 ms is good; over 1.8 s is poor. |
Redirects | Server response | Each redirect adds a round trip before the page starts loading. |
Compression and caching | Response headers | Brotli or gzip for HTML, and an ETag or Last-Modified header so repeat visits can revalidate. |
Render-blocking files | HTML head | Scripts in <head> without async, defer or type="module", and the number of stylesheets. |
Main image | HTML body | The likely largest image must not be lazy-loaded, and should be preloaded or have fetchpriority="high". |
Layout shift risks | HTML body | Images without width and height, and Google Fonts without display=swap. |
Viewport | HTML head | <meta name="viewport" content="width=device-width, initial-scale=1"> |
What is measured, and what is not
The checker has no browser. It cannot load your page on a throttled phone the way Lighthouse does, so it does not invent lab numbers for Largest Contentful Paint or Total Blocking Time.
What it reports is measured: the server response as a regular browser gets it, what the HTML makes the browser wait for, and, when Google has data for the site, Core Web Vitals from real Chrome users in the Chrome UX Report. Real-user data is what Google uses in search ranking.
Real-user data
- Data covers the last 28 days of Chrome visits on phones. It is shown for the exact URL when it has enough traffic, otherwise for the whole site.
- New and small sites often have no data. The other checks still run.
- Each metric is rated at the 75th percentile, so three in four visits must meet the threshold to count as good.
Common problems
- A slow server: pages built on every request without a CDN cache.
- Scripts in <head> without defer, often analytics, A/B testing or consent tools.
- The main image lazy-loaded, or discovered late because it is set by JavaScript or CSS.
- Images without width and height, so text jumps when they load.
- Pages drawn entirely by JavaScript, which show nothing until the scripts have downloaded and run.
Why the numbers differ from Lighthouse
Time to first byte here is one request from the checker’s server, not from a visitor’s phone, so it shows server speed rather than network speed. Lighthouse and PageSpeed Insights simulate a slow phone and network, and real-user data averages many devices and connections. Use this report to find causes, and real-user data to confirm the result.