Time to First Byte (TTFB) is a performance metric that measures the time between a browser's request for a page and the arrival of the first byte of data from the server. It serves as a primary indicator of web server responsiveness and network efficiency. Optimizing TTFB is a critical first step in improving user-centric metrics like First Contentful Paint (FCP) and Largest Contentful Paint (LCP).
What is Time to First Byte (TTFB)?
TTFB represents the total duration from the start of a navigation request until the browser receives the very first byte of the response. It is not a single event but the sum of several technical phases, including network latency and server processing time.
While often used to judge server performance, TTFB includes every step of the connection process. This includes: * Redirect time * Service worker startup (if applicable) * DNS lookup * TCP and TLS handshakes (connection setup) * Request processing and server response time
The 103 Early Hints exception
Modern technologies like 103 Early Hints can complicate TTFB measurement. Because Early Hints sends an interim response before the final document, the "first byte" may be recorded much earlier than the actual page content. In these cases, [site owners should use finalResponseHeadersStart to measure the time until the final document response] (MDN).
Why Time to First Byte (TTFB) matters
- Search Engine Rankings: Google and other search engines use speed as a ranking factor. Faster TTFB allows a site to respond more quickly than competitors, potentially improving visibility.
- User Retention: High TTFB leads to perceived lag. Users are less likely to abandon a site when they receive an immediate signal that the server is active and responding.
- Foundation for Core Web Vitals: Because TTFB occurs at the start of the loading process, a high TTFB makes it mathematically difficult to achieve a "Good" score for FCP or LCP.
- Diagnostic Value: It helps pinpoint whether a slowdown is happening or the network (Action 1), the server (Action 2), or the response delivery (Action 3).
How Time to First Byte (TTFB) works
TTFB is calculated through three distinct actions.
- The Request: The browser sends a request to the server. This phase is influenced by DNS lookup speed, the user's network connection, and the physical distance between the user and the server.
- Server Processing: The server receives the request and must generate a response. This often involves executing scripts, making database calls, and communicating with other systems on the network.
- The Response: The server sends the first part of the response back to the client. [Transmitting the request and the response over a network can account for almost 40% of the TTFB] (Fastly).
Best practices
- Implement a CDN: Using a Content Delivery Network places data closer to the user, reducing the distance requests must travel and lowering network latency.
- Use Caching: Store pre-generated versions of pages or database queries to avoid performing dynamic calculations for every request.
- Optimize Server Logic: Efficient server-side code and faster hardware resources reduce the time the server spends "thinking" before sending data.
- Aim for the 75th Percentile: To ensure a good experience for most visitors, [strive for a TTFB of 0.8 seconds or less] (web.dev).
Common mistakes
Mistake: Equating TTFB only with server speed. Fix: Remember that network latency and DNS lookups contribute to the total. A fast server on a slow network will still produce a poor TTFB.
Mistake: Focusing on TTFB while ignoring Gzip compression benefits. Fix: Understand that compression can sometimes increase TTFB because the server must finish compressing before sending the first byte. [Some websites see a 5 to 10 times increase in TTFB when using Gzip, yet achieve a 20% faster overall load time] (Wikipedia).
Mistake: Comparing TTFB across different platforms without checking their measurement methods. Fix: Different tools may handle Early Hints or redirects differently. Always use the same tool for "before and after" comparisons.
Examples
Example scenario: Static vs. Dynamic content A static HTML page hosted on a CDN will typically show a very low TTFB because there are no database calls or complex scripts to run. Conversely, a large dynamic request, such as a personalized dashboard pulling data from multiple databases, will likely have a higher TTFB due to server-side processing requirements.
Example scenario: The 0ms Resource Timing When measuring resources via JavaScript, you may see a TTFB of 0. This occurs when a resource is retrieved instantaneously from the browser cache or when a connection to a primary origin is already open.
FAQ
What is a "good" TTFB score? A good score is 0.8 seconds (800ms) or less. Scores between 801ms and 1,800ms "need improvement," while anything over 1,800ms (1.8 seconds) is considered poor.
How can I measure TTFB for my site?
You can use field tools like the Chrome User Experience Report (CrUX) and the web-vitals library. Lab tools like WebPageTest, Chrome DevTools (Network panel), and Google PageSpeed Insights also provide TTFB data.
How do I measure TTFB using JavaScript?
For navigation requests, you can use the Navigation Timing API. Specifically, the responseStart attribute of PerformanceNavigationTiming provides the timestamp of the first byte.
Does TTFB affect my SEO? Yes. Since TTFB affects the speed and responsiveness of your site, and search engines like Google use speed as a ranking factor, a high TTFB can negatively impact your search rankings.
Why does my TTFB increase when I turn on Gzip? Gzip compression requires the server to process the document before it can begin sending it. While this delays the "first byte," it reduces the total file size, which usually results in a faster overall page load for the user.
