Loading your website’s HTML quickly has a major impact on the visitor experience. After all, no page content can be displayed until the first part of the HTML has loaded. That is why the Time to First Byte (TTFB) metric matters: it measures how quickly the browser starts receiving the HTML response after navigation begins.
Generating the HTML document quickly plays a big role in reducing TTFB delays. But in reality, optimizing this metric involves much more. In this article, we will look at what else can cause poor TTFB and what you can do to fix it.
What components make up the Time to First Byte metric?
TTFB means the time to the first byte. But where is it measured from?
Different tools treat this differently. Some count only the time spent sending the HTTP request and receiving the response, ignoring everything else that needs to happen before a resource starts loading. However, when it comes to Google’s Core Web Vitals, TTFB starts from the moment users begin navigating to a new page. This means TTFB includes:
- Cross-origin redirects,
- Time spent connecting to the server,
- Same-origin redirects, and
- The HTML document request itself.
We can see an example of this in the following request waterfall visualization.
Server response time here is only 183 milliseconds, or about 12% of the total TTFB. Half of the time is instead spent on a cross-origin redirect — a separate HTTP request that returns a redirect response before we even make the request that returns the website’s HTML code. And once we make that request, most of the time is spent establishing a connection with the server.
Connecting to a server on the internet usually requires three network round trips:
- DNS: Looking up the server’s IP address.
- TCP: Establishing a reliable connection with the server.
- TLS: Creating a secure encrypted connection.
What does network latency mean for Time to First Byte?
Let’s count all the network round trips in the example above:
- 2 server connections: 6 round trips.
- 2 HTTP requests: 2 round trips.
That means that before receiving the first byte of our page response, we actually have to send data back and forth between the browser and the server eight times!
This is where network latency, or Round Trip Time (RTT), comes in, if we look at the time it takes for data to be sent to the server and for the response to arrive back in the browser. On a high-latency connection with a 150 millisecond RTT, completing those eight round trips will take 1.2 seconds. So even if the server always responds instantly, we cannot get a TTFB lower than this number.
Network latency depends heavily on the geographic distance between the visitor’s device and the server the browser connects to. You can see this effect in practice by running a global TTFB test on a website. Here we tested a site hosted in Brazil. We get good TTFB scores when testing from Brazil and the US East Coast. However, visitors from Europe, Asia, or Australia wait longer for the site to load.
What do Content Delivery Networks (CDNs) mean for Time to First Byte?
One way to speed up your website is to use a Content Delivery Network (CDN). These services provide a globally distributed network of server locations. Instead of every round trip traveling all the way to where your web application is hosted, browsers connect to the nearest CDN server, called an edge node. This greatly reduces the time spent establishing a connection with the server and improves the overall TTFB metric.
By default, the HTML request itself still has to be sent to your web application. However, if your content is not dynamic, you can also cache responses at the CDN edge node. That way, the request can be served entirely through the CDN, and the data does not travel across the world.
If we run a TTFB test on a website that uses a CDN, we can see that each server response comes from a regional data center close to the request location. In many cases, we get a TTFB below 200 milliseconds, thanks to the response already being cached at the edge node.
How to improve Time to First Byte?
What you need to do to improve your website’s TTFB score depends on which component contributes the most to it.
- A lot of time is spent establishing a connection: Use a global CDN.
- The server response is slow: Optimize your application code or cache the response.
- Redirects delay TTFB: Avoid redirect chains and optimize the server returning the redirect response.
Remember that TTFB depends on how visitors reach your website. For example, if they are logged in to your application, the page content probably cannot be served from cache. You may also see a TTFB spike when running an ad campaign, because visitors are redirected through a click-tracking server.
Monitor real-user Time to First Byte
If you want a more detailed view of what TTFB looks like for different visitors to your website, you need Real User Monitoring (RUM). This allows you to analyze how visitor location, login status, or the referring domain affects the real user experience.
DebugBear can help you collect real-user metrics for Time to First Byte, Google Core Web Vitals, and other page speed metrics. You can track individual TTFB components, such as TCP duration or redirect time, and analyze website performance by country, ad campaign, and more.
Conclusion
After examining everything involved in delivering the first byte of a website to a visitor, we have seen that reducing server response time alone is not enough and often will not even be the most impactful change you can make to your website.
The fact that your website is fast in one location does not mean it is fast for everyone, because site speed varies depending on where the visitor accesses it from.
Content Delivery Networks are an incredibly powerful way to improve TTFB. Even if you do not use any of their advanced features, simply using their global server network saves a lot of time when establishing a connection with the server.
