TTFB
Time to First Byte (TTFB) measures the time from the moment a user begins navigating to a page until the first byte of the server's response reaches the browser. It reflects server responsiveness and directly influences downstream loading metrics such as FCP and LCP.
- TTFB is the elapsed time from the start of a page request until the response's first byte arrives, serving as a diagnostic measure of server responsiveness.
- Per web.dev, a value at or below 0.8 seconds (800ms) is good, while anything above 1.8 seconds is poor, measured at the 75th percentile.
- It sums up redirects, DNS lookup, connection and TLS negotiation, and server processing time.
- It is not a Core Web Vital, but because it occurs before user-centric metrics like FCP and LCP, it sets the pace for them.
- You can reduce it with a CDN, caching, eliminating redirects, and stronger server infrastructure.
Overview
TTFB measures the time that elapses from the moment a user starts navigating to a page (startTime) to the moment the first byte of the server's response arrives (responseStart). In other words, it captures all of the waiting that happens just before the browser receives any actual content, making it a responsiveness metric that shows how quickly a server reacts to a request.
TTFB matters because it happens before every other loading metric. When the first byte arrives late, downstream metrics such as First Contentful Paint (FCP) and Largest Contentful Paint (LCP) are delayed along with it. TTFB therefore acts as the starting line for page loading performance.
Thresholds and Components
web.dev recommends the following thresholds for TTFB. Measured against the 75th-percentile user, a value at or below 0.8 seconds (800ms) is good, while a value above 1.8 seconds is poor. Most sites are advised to aim for 0.8 seconds or less.
TTFB is not a single action but the sum of several stages.
- Redirects: the time spent routing through other URLs
- Service worker startup time (where applicable)
- DNS lookup: resolving the domain name to an IP address
- Connection and TLS negotiation: establishing a secure connection with the server
- Server processing time: the interval between sending the request and generating the first response byte
One thing worth keeping in mind is that TTFB is a diagnostic metric and not part of the Core Web Vitals. A site that uses server rendering may post a somewhat higher TTFB yet still deliver better FCP and LCP, so the TTFB figure is best judged together with how the site delivers its key content.
Optimization Techniques
web.dev's guidance on optimizing TTFB recommends the following approaches.
- Hosting and server infrastructure: start by choosing hosting with ample memory and a modern backend stack.
- Use a CDN: distribute content to edge servers close to users to cut latency, and gain the benefits of HTTP/2 and HTTP/3, optimized TLS negotiation, and automatic compression.
- Caching: cache content at the edge with appropriate
Cache-Controlheaders. For high-traffic sites, even a short cache lifetime can improve TTFB significantly. - Eliminate redirects: remove same-origin redirects caused by incorrect schemes or missing slashes, and reduce HTTP-to-HTTPS redirects with the HSTS header.
- Stream the markup: instead of waiting to send a complete response, progressively send server-rendered output in chunks.
- 103 Early Hints: tell the browser in advance about the resources needed for rendering while the backend is still working.
- Monitor the backend: use the
Server-Timingheader to measure database queries, rendering, and cache performance in real-world conditions.
Basis
The definition, the 0.8-second and 1.8-second thresholds, the components, and the exclusion from Core Web Vitals all follow Google's official web.dev document "Time to First Byte (TTFB)." The optimization techniques are based on web.dev's "Optimize Time to First Byte" guide.