What this speed test actually measures
Most speed tests load your page once, from one place, and give you a score. That hides the two things that decide how fast your site feels in the real world: where the visitor is, and whether the CDN cache is warm at that location. This test measures both, per location:
- First visit — time until the full HTML document has arrived, on a fresh request. If the edge cache is cold, this includes the full round trip to your origin plus render time.
- Repeat visit — the same request again, seconds later, through the same edge location. If the response is cacheable, the first visit filled the cache and the repeat is served from the edge.
- Speedup — first ÷ repeat. A big speedup means caching works but the cache was cold; ~1× with a fast first visit means the cache was already warm; ~1× with a slow first visit means nothing is cached at all.
- Cache status transition — e.g. MISS → HIT, straight from the CDN's
response headers (for Cloudflare that's
cf-cache-status).
Hover over any time to see the split between TTFB and download, plus the raw measurement before calibration. For a TTFB-only view use the global TTFB test; for cache status in detail use the cache checker.
Reading the three typical patterns
| Pattern | What it means | What to do |
|---|---|---|
| Slow first, fast repeat (MISS → HIT) | Caching is configured correctly — but the cache was cold. Every first visitor per location pays the slow number. | Warm the cache so real visitors always get the repeat-visit speed. |
| Slow first, slow repeat (DYNAMIC / BYPASS) | The HTML isn't cached at all — every visitor everywhere waits for your origin. | Enable HTML caching (Cache Rule + Cache-Control); see the Cloudflare guide. |
| Fast first, fast repeat (HIT → HIT) | The cache was already warm at this location. This is the experience you want everywhere. | Check the other rows — usually only high-traffic regions look like this. |
Why the same site is fast in one country and slow in another
Distance to your origin and per-location caching explain most of the spread — but on Cloudflare specifically, several account-level factors change the numbers too:
- Per-location caches. Each of Cloudflare's 300+ data centers keeps an independent cache. A HIT in Frankfurt says nothing about São Paulo — that's the core reason this test measures per location.
- Plan-dependent routing. Which data center answers a request depends on peering and transit economics, and in practice higher Cloudflare plans get routed to closer colos more consistently in expensive regions (parts of Asia, South America, Australia). Check the Edge column: if a Sydney request is answered by a US colo, the extra ~150 ms is routing, not your cache. Look up any colo code in our data center list.
- Argo Smart Routing. A paid add-on that routes cache misses to your origin over Cloudflare's fastest private paths instead of the public internet — Cloudflare cites ~30% faster origin fetches. It speeds up the first visit in this test; it does nothing for a warm HIT.
- Tiered Cache. Free on all plans (once enabled): misses at small edge locations are answered by a larger upper-tier data center instead of your origin. It softens cold-cache penalties but doesn't remove them — the upper tier can be a continent away. More in our tiered caching glossary entry.
- Cache eviction. Low-traffic pages get evicted sooner at busy colos, so the same URL can flip between HIT and MISS over the day. Our production data post quantifies this.
Honest methodology
Three things most multi-location tests silently get wrong, and how we handle them:
- Relay overhead is subtracted. Our requests travel through a relay at each location. That relay leg adds latency a real visitor never pays. We measure it per location (a probe to an anycast endpoint next to the relay) and subtract it — hover over any value to see raw vs. calibrated.
- We measure the document, not a synthetic score. The times above are TTFB and full-HTML-download of your actual page — the part of loading that your CDN and origin control. Rendering, images and JavaScript run in the visitor's browser and belong in a lab tool like Lighthouse; mixing both into one score hides where the problem is.
- Running the test warms your cache. Any MISS in the first pass stored a copy at that edge. That's not a flaw — it's exactly the mechanism cache warming uses deliberately, on a schedule, from 90+ locations.
FAQ
Both visits show HIT — why do the times still differ?
When both visits are cache HITs, the edge answered both times and the remaining difference is connection-level variance: DNS resolution, TLS handshake timing and relay jitter. That's why the Speedup column shows "already warm" instead of a misleading multiplier in that case. We also pre-warm the DNS resolver at each location before measuring, so a cold resolver doesn't masquerade as a cache effect.
Why is the repeat visit sometimes not faster?
Three common reasons: the response isn't cacheable (DYNAMIC/BYPASS — every visit hits your origin), the cache was already warm on the first visit (HIT → HIT, both fast), or the CDN routed the repeat request to a different data center with its own cold cache. The cache column shows which one applies.
How is this different from PageSpeed Insights or Lighthouse?
Lighthouse loads your page once in a simulated browser and scores rendering, JavaScript and images. This test measures the network and caching layer — the same URL from 8 real locations, twice each. The two are complementary: a perfect Lighthouse score doesn't help a visitor in Singapore waiting 1.5 s for the first byte.
Does the test measure images, CSS and JavaScript too?
No — it fetches the HTML document only. Static assets are usually cached well by default; the HTML document is where most sites lose time, because CDNs don't cache it unless you configure it. It's also the request that blocks everything else.
What's a good result?
A well-cached site shows under ~200 ms full-HTML time on repeat visits in every location, and first visits that aren't much slower (because the cache is kept warm). Big first-vs-repeat gaps mean your real first visitors per region are paying the slow number — that's what cache warming eliminates.
Is this test free? Does it store my URLs?
Yes, free and no signup. Tests run live and results aren't stored — we keep a short-lived, in-memory rate-limit counter per IP and nothing else.
Big gap between first and repeat visit?
That gap is what your real first visitors pay in every region. warmup.rocks keeps the cache warm from 90+ edge locations on a schedule, so every visit performs like the repeat visit above.
Start your 7-day free trial