This article is sponsored by DebugBear
The visitor experience is greatly improved by loading your website HTML quickly. The first chunk of HTML must be loaded before the page content can appear. The Time to First Byte metric is very important because it measures the time after navigation that the browser receives the HTML response.
The HTML document must be generated quickly to minimize TTFB delays. Optimizing this metric is more complex than it seems. In this article, you’ll learn what else can lead to poor TTFB. You’ll also learn what you can fix it.
What components make up the Time to First Byte Metric?
TTFB stands Time to First Byte. What is the starting point?
Different tools handle it differently. Some tools only count the time it takes to send the HTTP request and get a response. They ignore everything else that must happen before the resource can load. Google’s Core Web Vitals starts the TTFB from the moment the user begins to navigate to a new webpage. TTFB includes the following:
Cross-origin redirects,
Time spent connecting to a server
Same-origin redirects are possible.
The HTML document itself.
This request waterfall visualization is a good example.
The server response time is only 183 microseconds or about 12%. The other half of the time is spent on a cross origin redirect — an HTTP request that returns a response that redirects us before we can make the request to return the website’s HTML. When we make this request, the majority of time is spent establishing the connection to the server.
Connecting to a web server typically requires three round trips over the network.
Lookup the server IP address using DNS
TCP: Establishing an reliable connection to the Server.
TLS: Creates a secure encrypted link.
What network latency means for Time to First Byte
Add up the number of round trips on the network in the example:
Two server connections: six round trips.
2 HTTP requests: 2 Round trips
This means that we have to send data between the browser and the server eight times before we get the first response for our page!
If we look at how long it takes to send a request to a server, and then receive a response from the browser, that’s what network latency is. On a high latency connection, with an RTT of 150 milliseconds, it will take 1.2 second to make eight round trips. Even if the server responds instantly, a TTFB of less than 1.2 seconds is impossible.
The network latency is influenced by the distance between the device of the visitor and the server to which the browser connects. You can see this in action by running a global TTFB on a website. Here I tested a Brazilian-hosted website. When testing from Brazil or the US East Coast, we get good TTFB results. Visitors from Europe, Asia or Australia have to wait for the site to load.
What content delivery networks mean for Time to First Bite
A Content Delivery Network (CDN) is one way to speed up a website. These services provide a global network of server locations. Instead of making a round trip to the server where your web app is hosted, browsers connect to a CDN server nearby (called an edge-node). This reduces the amount of time it takes to establish the server connection and improves your overall TTFB.
By default, HTML requests are still sent to the web app. If your content is not dynamic, you can cache responses at the CDN node. The request can then be served through the CDN, rather than having data travel across the globe.
If we run a TTFB on a website using a CDN, then we can see that every server response comes from a data center regionally close to the place where the request was made. In many cases, the TTFB is less than 200 milliseconds because the response has already been cached at the edge node.
How to Improve Time to First Byte
The most important factor in determining your website’s TTFB rating is its main contributor.
It takes a lot of time to establish the connection. Use a global CDN.
The server response is slow. Optimize your application code, or cache the response
Redirects delay TTFB : Avoid chaining redirects, and optimize the server returning redirect responses.
Remember that TTFB is dependent on how your visitors access your website. If they are logged in to your application, for example, the content of the page is unlikely to be served from cache. You may see an increase in TTFB if you run an ad campaign. Visitors are redirected via a click-tracking service.
Monitor real user time to first byte
You need real user monitoring if you want to know how TTFB is experienced by different visitors. You can then analyze how visitor location, login status or referrer domain affect real user experience.
DebugBear helps you collect real-user metrics for Time to First Byte (TTFB), Google Core Web Vitals and other page speed metrics. You can track TTFB components such as TCP duration and redirect time, and you can break down website performance based on country, ad campaigns, and other factors.
Conclusion
We’ve seen by looking at all the factors involved in serving the very first byte of your website to a user, that reducing the server response time alone is not enough. It’s often not the most impactful thing you can do for your website.
The speed of your website varies depending on where your visitor is accessing it.
Content Delivery Networks can be a powerful tool to improve TTFB. Even if you do not use their advanced features, using their global network of servers can save a lot time when setting up a server connection.