Website Speed Test

What This Tool Does

This test combines two sources that answer different questions, and keeps them visibly separate because conflating them is how speed tools mislead people.

Google’s PageSpeed Insights API supplies the Core Web Vitals. That includes Lighthouse lab data — one simulated load on a throttled connection — and Chrome User Experience Report field data, which is the 75th percentile across real Chrome users over the previous 28 days. These are Google’s own numbers, unmodified. There would be no credibility in substituting our own estimate of a metric Google defines and measures.

Our own probes supply server response time, measured independently of Google. This is the number that maps most directly to hosting quality, because it is time spent before any page content is involved.

Probes run from several regions at once, which is the piece PageSpeed Insights does not provide: it reports one server-response figure from one location, and that cannot separate a slow server from a distant one. Seeing the spread between regions makes the distinction visible.

Both halves are reported independently. If Google’s API is unavailable, the server timing is still shown and the Core Web Vitals section says it was not measured — it is never filled in with an estimate.

How to Read Your Results

Server response time

How long the server takes to send the first byte. Everything else on the page waits behind this, which is why it matters out of proportion to its size.

Lighthouse flags anything above 600 ms; Google’s threshold for real users is 800 ms. Both are shown so you can see which standard a figure is being judged against.

The spread between regions is as informative as the median. Uniformly high means the server or application is slow for everyone. A large gap between the nearest and furthest region means requests are travelling to a single origin, and a CDN would close most of it. Where the median passes but one region does not, the result is flagged as a warning rather than a pass — a median can hide a region where a quarter of your visitors are waiting.

Largest Contentful Paint

When the largest element in the viewport — usually a hero image or headline — finishes rendering. Google’s threshold is 2.5 seconds, and above 4 seconds is poor.

This is the metric users experience as “the page is slow”. The usual causes are a large unoptimised image, a slow server response delaying everything behind it, or render-blocking CSS and fonts.

Cumulative Layout Shift

How much content moves around while loading, as a unitless score. 0.1 or below is good, above 0.25 is poor.

High CLS is what makes someone tap the wrong thing because a button moved. It is almost always images or ad slots without reserved dimensions, or a web font swapping in and re-flowing the text.

Total Blocking Time and Interaction to Next Paint

Two views of the same problem: JavaScript occupying the main thread so the page cannot respond. TBT is the lab measure — 200 ms or less is good. INP is the field measure and the actual Core Web Vital, with a 200 ms threshold.

During blocked time the page looks ready but ignores taps, which users read as broken rather than slow. Third-party scripts are usually the largest contributor.

Lab data versus field data

The most important distinction on this page. Lab is one simulated load on a throttled connection — reproducible, available for any URL, and useful for diagnosis because it is repeatable. Field is what real Chrome users actually experienced over 28 days.

Google ranks on field data. When the two disagree, the field data is the one that counts, and disagreement is normal rather than an error: a simulation on a mid-range phone is not a description of your actual audience, who may be on faster devices, slower networks, or a different continent.

Field data is missing for most sites, because Google only reports it where there is enough traffic to anonymise. That is stated plainly when it happens rather than quietly filled in with the lab numbers.

Common Problems and Fixes

Server response time is over 600 ms

Work through the cheap fixes before considering hosting. Enable a page cache so repeat requests are not regenerated. Check for slow database queries — on a content management system this is usually a plugin doing work on every request. Put a CDN in front of the origin, which fixes the distance component entirely.

Hosting is the answer when responses are slow even when cached and static, or when every region is uniformly slow with no distance pattern.

LCP is above 2.5 seconds

Identify the element first — Lighthouse names it. If it is an image, serve it in a modern format, size it for the viewport it appears in, and preload it so discovery is not delayed. If it is text, the culprit is usually a web font blocking render; font-display: swap and preloading the font file address it.

If server response time is also high, fix that first. LCP cannot be faster than the time it takes to get the first byte.

CLS is above 0.1

Set explicit width and height on every image and video so the browser reserves the space before the file arrives. Reserve space for ad slots and embeds. Avoid inserting banners or notices above existing content after load.

Total Blocking Time is high

Audit third-party scripts, which are usually the majority. Load analytics, chat widgets and tag managers with async or defer. Remove anything nobody looks at — abandoned tracking scripts accumulate quietly and cost real time on every load.

Lab and field data disagree

Expected, not a fault. Field data is the 75th percentile of real visits over 28 days; lab data is a single simulated run right now. A recent improvement will appear in the lab immediately and take weeks to move the field figures.

Trust the field data for judging where you stand, and the lab data for diagnosing what to change.

What This Tool Cannot Tell You

• It tests one URL, not your site. Core Web Vitals are per page. A fast homepage says nothing about a heavy product page.
• Lab numbers vary between runs. A single run is a sample. Do not read a few points of score movement as a change.
• Field data is unavailable for most sites, and where present may describe the whole origin rather than the specific URL. The transcript says which.
• It cannot see logged-in or interactive experiences. Only what a public, unauthenticated visitor gets is measured.
• Sites blocking automated requests will block this. Our probes identify themselves honestly rather than impersonating a browser, so some servers will refuse them.