What Is TTFB? And How to Get Yours Under 200ms (2026 Guide)

1. What TTFB Actually Measures

TTFB (Time to First Byte) is the elapsed time between the browser requesting a page and the first byte of the response arriving. It's the sum of six phases:

1. DNS lookup — resolve yourdomain.com to an IP. 10–100ms.
2. TCP handshake — three-way SYN/SYN-ACK/ACK. 1 round trip.
3. TLS handshake — for HTTPS. Adds 1–2 round trips (or 0 with TLS 1.3 resumption).
4. HTTP request travel — the GET request to the server. Bounded by network latency.
5. Server processing — the slow part on WordPress: run PHP, query MySQL, assemble HTML.
6. First byte back to browser — response starts arriving.

Of those, steps 1, 2, 3, 4, and 6 are bounded by physics (speed of light, network distance). Step 5 — server processing — is where 80% of WordPress TTFB lives, and it's the one you can fix. See web.dev's full TTFB reference.

2. Why TTFB Matters for SEO

TTFB isn't a direct ranking factor, but it's the floor for LCP — and LCP is a ranking factor via Core Web Vitals. If your TTFB is 1.2s, your LCP is at best 1.2s + image download time = ~2.0s. That's borderline. If TTFB is 200ms, LCP has a 2.3s budget to download and paint the hero — plenty of room to pass Core Web Vitals.

Google's own Page Experience guidance treats fast server response as one of several "good UX" signals. And on a practical level, crawlers with limited crawl budget will index fewer pages on slow sites — that's the indirect SEO cost.

3. How to Measure Your TTFB

Quick check (command line)

curl -o /dev/null -s -w "%{time_starttransfer}\n" https://yourdomain.com/

Prints TTFB in seconds. Run 3 times — first may be slow (cold cache), next two are warm.

Lab tools

• WebPageTest — shows TTFB broken into DNS / connect / SSL / wait phases.
• PageSpeed Insights — reports "Server response time" (= TTFB) as a diagnostic.
• Our PageSpeed tool — same Lighthouse engine.

Field tools

• Google Search Console > Core Web Vitals reports the CrUX field data, which includes TTFB at the 75th percentile.
• The web-vitals JS library reports navigation.responseStart - navigation.requestStart per visit.

4. 12 Ways to Cut TTFB

1. Move to NVMe + LiteSpeed hosting. Single biggest lever. Cuts TTFB from 1,000ms to <200ms on a typical WordPress site.
2. Enable full-page caching. LSCache / WP Rocket / W3 Total Cache. Cached HTML bypasses PHP and MySQL entirely — TTFB drops to <100ms.
3. Put Cloudflare in front. Cloudflare caches HTML at the edge (especially with APO), serving from a location near the user.
4. Enable TLS 1.3 and session resumption. Cuts 1 round trip off handshake.
5. Use HTTP/3 (QUIC). 0-RTT resumption on repeat visits — essentially zero handshake cost.
6. Upgrade to PHP 8.3. 30–45% CPU reduction over PHP 7.4.
7. Add object caching (Redis/Memcached). Slashes MySQL query time for logged-in users and uncached requests.
8. Optimize MySQL queries. Use Query Monitor to find N+1 queries, missing indexes, slow meta lookups.
9. Kill heavy plugins that run on every request. Related-posts plugins, real-time analytics.
10. Put servers near your users. Cheap hosts often place your server wherever is cheapest. Pick a host with your primary traffic region.
11. Use a persistent object cache. Redis object cache keeps WordPress options and transients out of MySQL.
12. Enable Early Hints (HTTP 103). Lets the browser preload critical assets before the full HTML lands. Cloudflare supports on all plans.

5. When You Can't Improve TTFB Further

TTFB has a physical floor. From the US west coast to a server in Frankfurt, the round-trip time is ~160ms before you add any server processing. That's the speed of light plus network switching overhead — not fixable.

To get TTFB under 200ms globally, you need either:

• Multi-region hosting (most sites don't need this)
• A CDN that caches HTML at the edge (Cloudflare APO does this)

With Cloudflare APO serving cached HTML from the edge, even a single-region origin server can deliver sub-100ms TTFB everywhere. That's the sweet spot for most WordPress sites.