Why is this score different from PageSpeed Insights?

They measure different things. PageSpeed Insights runs a headless browser and reports Core Web Vitals — LCP, CLS, INP — including field data from real Chrome users. We measure the server response and the delivered HTML from our own fetch. Use this to diagnose server and payload problems; use PSI for rendering and real-user performance.

Google's 'good' threshold is 800 ms; under 300 ms is genuinely fast. Above 1.5 s you almost certainly have an uncached, database-backed page render, and that is where to look first.

My site is fast for me but scores badly here. Why?

You are probably being served from a warm cache, geographically close to the origin, on a desktop connection. Our probe is a cold, single request from a different network. That difference is exactly what a first-time mobile visitor experiences.

Does page speed affect Google ranking?

Yes, but modestly. Core Web Vitals are a real signal and act mostly as a tiebreaker between pages of similar relevance. Speed's larger effect is on bounce rate and conversion, which is usually the better reason to invest in it.

Website speed test

This is a server-side measurement of the things you control on the wire: how long your server takes to answer, how much HTML it sends, whether it is compressed and cacheable, and how many resources block the first paint. It is a lab probe, not field Core Web Vitals — read the caveat below before comparing it to PageSpeed Insights.

11%score below 55 on speed

Across 959 websites analyzed

Measured across every site in our public database.

Why this matters

TTFB is the one number you can actually fix

Everything else in a page-speed report is downstream of it. If your server takes 1.5 seconds to send the first byte, no amount of image optimisation recovers that — the browser has not started work yet. It is also the metric most sensitive to cheap fixes: caching, a CDN, and moving off an overloaded shared host routinely cut it by 70%.

Speed is a ranking factor, but a weak one — and a strong conversion factor

Core Web Vitals affect ranking mostly as a tiebreaker between comparable pages; content relevance dominates. The reason to care is money on the other side: bounce rate climbs steeply between 1 and 3 seconds, and mobile shoppers on Korean 4G are exactly the population that abandons first. Treat speed as a revenue metric that also happens to help SEO.

How to fix it

1. Cache the HTML before optimising anything else
If every request rebuilds the page from the database, that is your TTFB. Full-page caching (Cloudflare, Varnish, a WordPress cache plugin, or static generation) turns a 1200 ms response into a 90 ms one, and it is usually a configuration change rather than a rewrite.
2. Turn on compression
gzip or brotli on HTML, CSS and JS typically cuts transfer by 70–80%. It is one directive in nginx/Apache and a toggle on every managed host. Sites still shipping uncompressed HTML in 2026 are almost always doing it by accident.
3. Get scripts out of the critical path
Every `<script src>` and stylesheet in `<head>` delays first paint. Add `defer` to scripts that don't need to run before render, `async` to independent third-party tags, and audit what those tags are — chat widgets, heatmaps and multiple analytics libraries are the usual cause of a slow site that 'has no images'.
4. Give every image a width and height
Not for speed itself but for layout stability (CLS): without dimensions the browser cannot reserve space, so content jumps as images load. Combine with `loading="lazy"` on below-the-fold images and modern formats (WebP/AVIF) for the actual byte savings.

Want this fixed rather than explained?

The content-level part of this we do ourselves. The server-level part — compression, caching, response time — comes as a written spec for your host. Both are covered by the same fixed price.

See fixed prices →

Frequently asked questions

Why is this score different from PageSpeed Insights?: They measure different things. PageSpeed Insights runs a headless browser and reports Core Web Vitals — LCP, CLS, INP — including field data from real Chrome users. We measure the server response and the delivered HTML from our own fetch. Use this to diagnose server and payload problems; use PSI for rendering and real-user performance.
What is a good TTFB?: Google's 'good' threshold is 800 ms; under 300 ms is genuinely fast. Above 1.5 s you almost certainly have an uncached, database-backed page render, and that is where to look first.
My site is fast for me but scores badly here. Why?: You are probably being served from a warm cache, geographically close to the origin, on a desktop connection. Our probe is a cold, single request from a different network. That difference is exactly what a first-time mobile visitor experiences.
Does page speed affect Google ranking?: Yes, but modestly. Core Web Vitals are a real signal and act mostly as a tiebreaker between pages of similar relevance. Speed's larger effect is on bounce rate and conversion, which is usually the better reason to invest in it.