Time to First Byte (TTFB)
The time it takes for a browser to receive the first byte of data from the server.
Detailed Explanation
TTFB is a fundamental measurement of server responsiveness and network latency. It includes DNS lookup, TCP handshake, TLS negotiation, and the server's internal processing time. A slow TTFB (over 600ms) will delay all other performance metrics. Improving TTFB involves using a CDN, optimizing database queries, and leveraging edge caching.
Quick Summary
TTFB is the time from request start to the first byte of the response arriving, covering DNS, TCP, TLS, and the server actually doing its work. It's the floor for everything else on the page.
Key Takeaways
- Target: under 800ms for a good experience; under 200ms is excellent.
- Includes connection setup (DNS + TCP + TLS) plus server processing.
- CDN edge caching is the single biggest lever, turning origin TTFB of 500ms into edge TTFB of 30ms.
- Edge rendering and HTTP/3 reduce setup latency; smarter caching reduces server processing time.
- TTFB is field-measured by the browser via the Performance API; check `responseStart - startTime`.
When to use it
- Diagnosing whether a slow page is the network/server or the frontend.
- Sizing investments in CDN, edge functions, and caching layers.
- Setting SLOs on API endpoints (p50 / p95 / p99 TTFB).
- Reducing perceived latency for users far from the origin.
Common Mistakes
- Optimizing the frontend while ignoring a 1500ms backend TTFB, most of the load time is already gone.
- Measuring only from the dev machine (next door to the origin), real users have ~10× the network latency.
- Cacheable responses served fresh from origin every time; basic CDN configuration would cut TTFB by 10×.
- TLS misconfiguration (no session resumption, no OCSP stapling) adding 100–300ms per cold connection.
Time to First Byte (TTFB), Frequently Asked
How do I improve TTFB on dynamic pages?
Layer caching: edge cache for the same response across users, application cache (Redis) for shared expensive computations, database indexes for the per-user query. Then move what can be precomputed to background jobs, leaving the request path with cheap reads.
Is TTFB the same as server response time?
Close, but TTFB also includes DNS + TCP + TLS setup time. "Server response time" usually refers to just the server-side processing slice. A slow TTFB with fast server time means your network/connect setup is the problem.