Free tool · no signup required

How fast is your site — everywhere?

Measure your Time to First Byte from six locations on four continents at once. One number from one server tells you nothing — your visitors are everywhere.

Measures full TTFB including redirects · calibrated: relay overhead per location is measured and subtracted, so values approximate a visitor at that location · also reads the CDN cache status.
Tested fromTTFBCacheEdgeHTTP

What is TTFB?

Time to First Byte is the time from sending a request until the first byte of the response arrives. It's the part of page speed your visitor can't scroll past: nothing renders, nothing paints, nothing hydrates until the first byte lands. TTFB is the floor under every other performance metric — a slow TTFB pushes back LCP and everything after it.

What's a good TTFB?

TTFB (from a well-connected server)VerdictWhat it usually means
< 200 ms✅ FastServed from a CDN edge cache near the test location
200 – 600 ms⚠️ OkayCache hit far away, or a quick origin response
> 600 ms❌ SlowOrigin render: cold cache + geographic round trip + server time

Google's field threshold (Chrome UX Report) is more forgiving — ≤ 800 ms counts as good — because it includes slow mobile networks. This tool measures from well-connected data centers, so the numbers isolate your side of the equation: cache, CDN and origin speed, not the visitor's network.

Why TTFB differs per location — and what to do about it

The same URL can answer in 40 ms in Frankfurt and 1,400 ms in Singapore. Two reasons:

The fix order that gives the most win per effort:

  1. Cache HTML at the edge. Most CDNs don't cache HTML by default (Cloudflare shows DYNAMIC). Enable it with a cache rule and correct Cache-Control headers. And make sure the bytes that do travel are small — our compression test shows whether Brotli or Zstandard is actually enabled.
  2. Keep the cache warm in every location. Caching only helps when the copy is actually there. Long-tail pages and low-traffic regions run cold — cache warming fixes exactly that, and it's what warmup.rocks automates from 90+ edge locations.
  3. Speed up the origin. Server-side caching, fewer database queries, a faster host — this helps every MISS that still happens.

FAQ

Does this test include DNS and TLS time?

Yes — the measurement starts at request start, so DNS resolution, TCP/TLS handshake and any redirects are included. That's what a first-time visitor experiences.

How is the measurement calibrated?

Our requests travel through a relay at each location, which adds latency a real visitor there never pays. We measure that relay overhead per location (a tiny probe to an anycast endpoint sitting next to the relay) and subtract it — hover over any TTFB value to see the raw measurement and the subtracted overhead. Most single-probe tools skip this step and quietly report the inflated number.

Why did the second run get much faster?

Your first test warmed the cache: every MISS stored a copy at that edge location. That's cache warming in action — the same effect a scheduled warmer maintains permanently, instead of only after someone runs a test.

My TTFB is slow everywhere. Cache or origin?

Look at the cache column. If it says HIT and it's still slow, the problem is unusual (huge headers, slow middleware at the edge). If it says MISS, DYNAMIC or shows no CDN at all, the time is your origin's — enable edge caching first, it dwarfs most server-side optimizations.

Is this the same as my PageSpeed / Lighthouse TTFB?

Related but not identical. Lighthouse measures one request from one place (often simulated). This tool measures six real locations in parallel — closer to what your global audience actually gets, and it shows the variance that a single number hides.

Slow rows in the table? That's a cold cache.

warmup.rocks requests your pages from 90+ edge locations on a schedule, so every location answers like your fastest one. Hit ratio reported per location, per run.

Start your 7-day free trial