Website performance test
Ten checks on how fast your site really is — seven measured directly by our servers, three by Google Lighthouse. You get a Speed score and a prioritised list of fixes.
Methodology
The ten performance checks
Each check carries a weight reflecting how much it actually affects visitors. Heavier checks move the score more.
How long the server takes to send its first byte. Measured directly by our servers.
Whether HTML, CSS and JS are sent gzip- or Brotli-compressed.
Scripts and stylesheets in the head that delay the first paint.
Cache-Control, ETag and Last-Modified headers that make revisits cheap.
The weight of the HTML itself, before images and scripts.
Whether the server negotiates HTTP/2 or HTTP/3 rather than HTTP/1.1.
How many hops a visitor makes before the real page loads.
When the main content finishes rendering. Google's target is under 2.5 s.
How much the layout jumps while loading. Google's target is under 0.1.
How long the main thread is frozen, making taps feel unresponsive.
Why two measurement sources?
Server-side facts — compression, caching, protocol, response time — are things we can measure exactly by making a real HTTP request. The Core Web Vitals are different: they describe what a browser experiences while painting the page, so they need an actual browser. We hand that job to Google Lighthouse via the PageSpeed Insights API, and if it is unavailable those three checks are marked not tested and excluded from the score rather than counted as failures.
Speed is only one vital
A fast site that search engines cannot read, or that goes down twice a week, still has a poor overall state. Check the other two vitals too.