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.

Multi-region probing is not currently enabled, so these measurements come from a single location. That is still a real measurement and it is labelled as one vantage point in every result — but it cannot yet distinguish a slow server from a distant one, which is what the multi-region version is for. Results say plainly which kind of measurement produced them.

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.

This figure is measured from one location, so it reflects the distance between our server and yours as well as the server’s own speed. A visitor on another continent will see a slower number.

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.
• Server timing comes from one location. Multi-region probing is built but not currently switched on, so the figure includes the distance from our server to yours and cannot separate a slow origin from a distant one.