What the number includes
The common mistake is reading TTFB as "how long my backend took". It is not. It is the sum of six things, and server processing is only one of them:
- Redirects — every hop is a full round trip before the real request even begins.
- DNS lookup — resolving the hostname, if it is not already cached.
- TCP connection — the handshake with the server.
- TLS negotiation — certificate exchange and key agreement for HTTPS.
- Request travel time — the request crossing the network.
- Server processing — your application actually doing the work.
For a visitor on another continent, the first five can easily outweigh the sixth. A backend that responds in 40 ms can still produce a 900 ms TTFB if the request had to cross an ocean, negotiate TLS, and follow a redirect on the way.
Google's thresholds treat 800 ms or less as good and above 1.8 s as poor. TTFB is a diagnostic, not a Core Web Vital — search ranking does not depend on it directly. It matters because it constrains the metrics that do: LCP can never be faster than TTFB, so a 2-second first byte makes a good LCP arithmetically impossible.
Finding the phase to blame
Because TTFB is a sum, improving it means identifying which term dominates. Any tool that breaks a request into connection phases will show you: the HTTP Request Timing tool reports DNS, connect, TLS and response timing separately for a real browser load, and HTTP Headers exposes the redirect chain and cache headers behind it.
Work through them in order of how cheap they are to fix:
Redirects. The cheapest win available and the one most often left in place.
http://example.com → https://example.com →
https://www.example.com is two extra round trips on every uncached visit. Link
to and advertise the final URL, and collapse redirect chains so each legacy URL points
straight at its destination rather than at another redirect.
DNS. Usually small and usually cached, but a very high TTL-less record or a slow authoritative nameserver shows up here. Worth checking, rarely the culprit.
TCP and TLS. Both scale with physical distance, because both are round trips. This is the term a CDN attacks: terminating the connection at an edge near the visitor cuts handshake time even when the content still comes from your origin. HTTP/2 and HTTP/3 reduce the cost of additional connections; session resumption avoids repeating the full TLS handshake for returning visitors.
Server processing. The usual suspects are uncached database queries, N+1 query patterns, cold starts on serverless platforms, and synchronous calls to third-party APIs during page render. Caching the rendered response — even for a few seconds — converts the worst case into the common case for high-traffic pages.
Why your TTFB looks different in every tool
Two tools will rarely agree, and usually neither is wrong. They differ on:
- Where they measure from. A test from a data centre in the same region as your origin will report a fraction of what a phone three time zones away experiences.
- Whether redirects are counted. Some tools time the final URL only; others include every hop.
- Cache state. A warm CDN edge answers in milliseconds; the first request after a purge pays full origin cost.
- Lab versus field. A single controlled run is not the same measurement as the 75th percentile of real visits — see real user monitoring.
Common mistakes to avoid
Assuming a slow TTFB means slow application code. Check the redirect chain and the connection phases before you go profiling queries. Plenty of "server performance problems" turn out to be two redirects and a distant origin.
Optimising TTFB in isolation. It is a floor, not the whole story. Getting from 600 ms to 300 ms is worth little if render-blocking resources then cost two seconds.
Measuring only from one location with a warm cache. That combination is the best case your site will ever produce and tells you nothing about the visitors having the worst time.
Ignoring the first-visit case. Your own TTFB is flattered by DNS caching, an open connection, and a warm CDN edge. A first-time visitor pays for all of it.
Troubleshooting
Why is TTFB fine for me but poor in field data? You are almost certainly close to the origin with warm DNS and connection reuse. Field data covers everyone, including first-time mobile visitors far away.
Why did TTFB get worse after adding a CDN? Usually a low cache hit rate. If most requests miss the edge, you have inserted an extra hop between visitor and origin without gaining a cached response. Check hit ratio and cache headers before concluding the CDN is the problem.
Why does TTFB spike periodically? Cache expiry is the classic cause — every entry expiring at once sends a burst of traffic to the origin. Scheduled jobs competing for database resources produce the same pattern. Continuous measurement is what makes a periodic spike visible at all; a one-off test will usually miss it.
Why is TTFB high only on some pages? Those pages are doing more work, or they are the ones that cannot be cached — search results, personalised dashboards, and anything behind authentication typically bypass the cache entirely.