TTFB — Time to First Byte — is the tax every visitor pays before anything renders. It compounds: a 600ms TTFB makes a 1s render into a 1.6s LCP. And it is the metric most often misdiagnosed, because it has four different sources that each need a different fix.
What TTFB actually contains
- Network time: DNS, TCP, TLS round trips between visitor and server (40–100ms domestic, more international).
- Server queue time: waiting for a free PHP worker (shared hosting under load — the 503-adjacent failure in the 503 guide).
- Application time: WordPress executing — plugins, theme, database.
- Cache miss penalty: when no cached page exists, all of application time is paid; when the cache hits, it nearly vanishes.
Fix 1: Make the page cache hit (the only fix that matters first)
Cached TTFB on our test stack: 91–103ms. Uncached: 480–610ms. The delta is application time — PHP and MySQL work the page cache skips entirely. Get one page-cache layer working and verify it serves: curl the URL and check the cache plugin’s header. The layer options and conflicts: the caching guide.
Fix 2: Shrink uncached application time
Caches do not help crawlers, first-time visitors, or logged-in users — the uncached TTFB is the honest cost. Reduce it:
- Object cache (Redis): cut our store’s uncached generation 480→190ms — the setup in the Redis guide.
- Plugin diet: Query Monitor’s queries-by-component panel names the slow plugins — the method in the Query Monitor guide.
- Theme weight: heavy themes execute more code per request — the diagnostic in the theme guide.
Fix 3: Cut network time
TLS and DNS round trips: modern TLS 1.3 saves a round trip; HTTP/2/3 multiplexing matters after the first byte; a CDN shortens physical distance for international visitors (the honest EU measurements in the CDN comparison). These are seconds of config, but they only matter once the cache works.
Fix 4: Fix the hosting tier
If uncached TTFB stays past ~600ms on a healthy site with object cache, the hosting is the ceiling: slow disks, throttled CPU, or worker starvation. This is a procurement decision, not an optimization one — the benchmarks in the B2B study show what adequate tiers look like.
Diagnosing which source dominates
curl with timing breakdown from the server itself separates the sources cleanly:
curl -o /dev/null -s -w "dns %{time_namelookup}s | connect %{time_connect}s | ttfb %{time_starttransfer}s | total %{time_total}s
" https://yoursite.com/
Compare with and without a cache-buster query string — the gap is your application time, the floor is your network time. The free audit reports both, cached and uncached.
Under 200ms cached (double digits is excellent), under 600ms uncached. TTFB compounds into LCP directly — every 100ms here delays first paint equally. Either the cache is not actually serving (verify via response headers), or the number you see is uncached. Both layers — cached and uncached — must be measured separately. For distant visitors, yes — it shortens network round trips. It cannot fix slow application time: a page cache and object cache must work first. curl -w timing from the server: namelookup/connect/starttransfer breakdown, compared with and without cache-buster. The difference between the two runs is application time.What is a good TTFB for WordPress?
Why is my TTFB high even with caching?
Does a CDN lower TTFB?
How do I measure where TTFB goes?
