Website speed test

InstrumentMeasured + benchmarkedNothing stored
Measures via the PageSpeed Insights v5 API, mobile strategy.

What this measures

Two independent layers. The first is our own measurement: this instrument fetches the document itself and reports server response time, transfer size, compression, security headers, third-party count, cookies set before any interaction, and document-level accessibility signals. It always runs, from a single request, with no JavaScript executed — the same method as our sector observatories.

The second layer is Google’s. Field data is the Chrome UX Report: the 75th-percentile Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift experienced by real Chrome users on this page over the last 28 days. It is the same dataset search ranking systems reference, and it only exists for pages with enough traffic. Lab data is a single Lighthouse run on an emulated mid-range phone over a throttled connection — reproducible, but a simulation. When that layer is unavailable the instrument says so and still reports everything it measured directly.

The documented “good” thresholds are 2.5 s for LCP, 200 ms for INP, and 0.1 for CLS, each assessed at the 75th percentile of real page loads. A page can score well in the lab and still fail in the field; when the two disagree, the field wins — users are the measurement that matters.

The benchmark

A millisecond figure on its own says little. Every measurement is therefore ranked against the full observatory corpus — all 270 homepages we have measured with this same method, across every sector on the site and the ones we have since retired — so the result reads as a position, not a number: a page beating 93% of the corpus on server response is doing well, whatever its absolute figure. The corpus grows as sectors are added.

How to read the result

Start with field LCP: if it exceeds 2.5 s, the largest element is arriving late — typically server response time, render-blocking resources, or an unoptimized hero image. A high INP points to long tasks on the main thread. Field CLS above 0.1 almost always traces to images without dimensions or late-injected content. The lab TTFB row isolates the server’s share of the delay. For the mechanics behind each metric, see Core Web Vitals: how the metrics work.