Performance

TTFB Under 200 ms: How to Hit the Best Score on WordPress

9 Jul 2026 · 7 min read


Under 200 ms TTFB counts as the best score — that takes more than any single optimisation; it takes a properly tuned stack of hosting, caching and CDN working together.

If your TTFB is still above 800 ms, read Reduce TTFB on WordPress first — it covers the fundamentals and the most common causes. This article picks up where the basics already sit, and shows concretely what makes the difference between "good" (200-500 ms) and "very good" (under 200 ms).

Why the 200 ms mark is so demanding

At 500 ms TTFB, an active caching plugin is usually enough. Under 200 ms, every single component in the response chain counts:

  • Network latency between the visitor and the server (distance, DNS, TLS handshake)
  • Time until the cache hits — edge cache, object cache, PHP execution
  • Server load at the moment of the request

From here on, "install a plugin" is no longer enough — the entire stack has to fit together.

The four levers that actually get you under 200 ms

1. Edge caching instead of plain server caching

A normal page cache serves HTML from the origin server — including the latency between the visitor and the server location. To stay consistently under 200 ms, the HTML itself has to live at the edge, not just the assets.

  • Cloudflare Cache Everything + page rules for HTML responses
  • Full-page caching directly at the hosting provider (e.g. LiteSpeed Cache with QUIC.cloud CDN, WP Rocket + your own CDN)
  • Check the cache hit rate: response header cf-cache-status: HIT or the equivalent header for your CDN

2. Server location and anycast routing

Even the fastest cache doesn't help if requests are routed across the continent first. For a DACH audience:

  • Host the origin server in Germany or directly neighbouring countries
  • Use an anycast network (Cloudflare, Bunny CDN) so every request automatically hits the nearest edge location
  • Enable HTTP/3 — noticeably reduces handshake overhead, see HTTP/3 for WordPress

3. Cache warmup instead of cold-cache hits

A single uncached request can take 1-3 seconds and immediately wreck the TTFB average. For consistently low values:

  • Cache preloading after every purge (cache clear on a plugin update, post change, etc.)
  • A crawler or cron job that immediately re-requests important pages after the cache is cleared
  • Deliberately raise the cache lifetime when content changes rarely

4. Object cache for the rest of the requests

Even with edge caching, there are requests that have to reach the origin — logged-in users, WooCommerce cart, personalised content. For those:

  • Redis or Memcached as a persistent object cache
  • Reduce database queries to a minimum (Query Monitor shows the outliers)
  • OPcache with enough memory so PHP bytecode isn't recompiled repeatedly

A realistic example

A WordPress site with WP Rocket, shared hosting in Germany, no CDN, averaged 480 ms TTFB. After the changes:

Measure TTFB afterwards
Starting point (server cache, no CDN) 480 ms
+ Cloudflare with Cache Everything 210 ms
+ Cache preloading after every cache clear 160 ms
+ HTTP/3 enabled 140 ms

The biggest jump came from edge caching — not from the hosting upgrade.

Keeping TTFB under 200 ms, not just hitting it once

A single measurement under 200 ms doesn't say much — TTFB fluctuates with traffic, cache state and time of day. turbometrics measures TTFB on every scheduled scan from multiple locations and alerts you as soon as the value rises above your threshold. That way you can see whether 200 ms was an outlier or holds up over time — also via live data with your visitors' real p75 TTFB.

Checklist for consistently under 200 ms

  1. Check the edge cache hit rate — if it's well under 90%, that's the first lever
  2. Verify the server location — does it match your audience?
  3. Enable HTTP/3, if you haven't already
  4. Set up cache preloading, so cold-cache hits stay rare
  5. Object cache (Redis/Memcached) for logged-in and dynamic requests
  6. Monitor TTFB continuously, not just as a one-off measurement

Conclusion

Under 200 ms TTFB isn't a hosting feature — it's the result of edge caching, the right server location, cache warmup and a clean object cache. If you're already under 500 ms on the fundamentals from Reduce TTFB on WordPress, these four levers will reliably get you into the green range.

Measure your TTFB for free now — with turbometrics you see instantly where you stand.

Try turbometrics for free

Scans, monitoring and live data — start for free, no subscription needed.

Get started for free