Time to First Byte (TTFB)
How long from the start of the request until the browser receives the first byte of the response — the server-and-network portion of load time, before any rendering begins.
Vanity Risk
TTFB measured from a location next to your origin server is a number that flatters the infrastructure and misleads the team. Only the field P75 across real visitor geographies reflects the latency users actually pay before the page even begins to load.
What it measures
Backend and delivery speed. TTFB is everything that happens before the browser can do anything: DNS lookup, connection setup, redirects, and the server actually generating the response. It is a diagnostic metric, not a Core Web Vital, but it is the floor under every paint metric — LCP and FCP can never be faster than TTFB. A poor TTFB means front-end optimization is rearranging deck chairs; the fix is upstream.
Benchmarks
- Good: ≤ 0.8s at P75
- Needs improvement: 0.8s–1.8s at P75
- Poor: > 1.8s at P75
- Thresholds: Google web.dev (field data, 75th percentile; TTFB is a diagnostic metric, not an official Core Web Vital)
Figures reviewed June 2026. Benchmarks vary by source and drift over time — treat as directional and verify against your own data.
What to watch
- Above 0.8s at P75: The server or delivery path is slow. Common causes: uncached dynamic rendering, slow database queries in the request path, no CDN or edge caching, or chains of redirects. Each adds latency before a single pixel can paint.
- Geographic spread in the field: TTFB that is fast near your origin and slow elsewhere is a delivery problem, not an application one. A CDN or edge rendering usually moves it more than backend tuning.
- Spikes correlated with traffic: TTFB that degrades under load points at a capacity or caching ceiling rather than a code path. Look at the response-time distribution during peak windows, not the daily average.
In practice
A content site had TTFB at 1.9s at P75 and had spent a sprint optimizing images with no effect on load metrics. Every page was rendered dynamically on each request with no caching. Adding edge caching with a short TTL for the mostly-static pages brought TTFB to 0.2s, and LCP improved by nearly the same 1.7s — because the paint metrics had been waiting on the server the entire time. The image work only paid off once the floor was removed.
Illustrative scenario — a representative composite, not a specific company.
Related: First Contentful Paint — the first thing TTFB gates; if both are poor, fix TTFB first.; Largest Contentful Paint — TTFB is the hard floor under LCP; front-end work cannot beat a slow server.; Conversion Rate — server latency compounds across multi-step funnels, where every step pays the TTFB cost again.