Cookies help us create our services and enhance your experience. By using this site you agree to our use of cookies. Okay.

Server Density

Time to First Byte

Monitor and Diagnose Slow Server Responses

How long are users waiting for your server?

Something went wrong. Please check your URL carefully, then try again.

What is Time to First Byte?

When a user requests a web page, several things have to happen before they receive a response:

  1. The domain name is resolved as an IP address. This process is handled by the Domain Name Service (DNS)—a distributed network of servers that provide only this function.
  2. Once the IP address is known, the user's device must open a connection to the server. This is known as the TCP/IP Handshake. If the website is served over HTTPS, there’s an additional step to this process known as the SSL Handshake. This is itself an interesting process, and DNSimple has a nice guide to SSL certificate chains—the process of checking the trustworthiness of a site’s SSL certificate.
  3. Now that the connection is open, the server can begin working on its response to the user's request. This stage could include many different moving parts—making database queries, redirecting from one URL to another (at which point, in many cases, the process begins again), or using a server-side language such as PHP to generate, fetch and render an HTML page.
  4. The server completes its work and begins to send a response. Each response is broken into many small “packets” of data, and sent out over the internet. These packets reach the user’s device, where they are pieced back together to render the page. When the user receives the first response packet, that’s when we register Time to First Byte (TTFB).
  5. Only now that the response has been received, the user's browser starts working on all the other important things: JavaScript, CSS, external resources, etc. But these don't form part of the TTFB.

What are the causes of slow TTFB?

The first thing to know is slow Time to First Byte doesn't necessarily mean you have a problem. There could be perfectly valid reasons for a slower TTFB—see “When not to worry” section below. Generally speaking, though, you should investigate if your TTFB:

varies significantly over time
varies significantly over time
varies a lot by location
varies a lot by location
is slower than 200 ms
is slower than 200 ms

Server Issues

The issues of most interest are those at the server level. TTFB can mask many infrastructure-level issues, including:

Web-based speed tests won’t uncover these issues—all that can be seen from the outside is the server’s slow overall response time. So, when measuring changes to your Time To First Byte, it’s important to consider it together with other metrics, measured from within the machine itself: free disk space, database response times, CPU usage, and I/O throughput. Measuring the correlations between these and TTFB will allow you to see which issues in your infrastructure are actually causing problems for the end user.

Network Issues

Because TTFB includes the time taken for the packets to travel over the wire, network latency can matter a great deal. If packets have to travel from a website in Japan to a browser in Argentina, there’s quite some distance to cover. Distributed networks and CDNs solve some of these issues, but add expense and complexity. The only practical way to identify bottlenecks at the network level is by testing overall site response times from multiple locations—for example, testing from where your customers may be.

At Server Density, we monitor our customer's websites from multiple locations around the world to determine exactly how network infrastructure and latency affect response times (though it’s difficult to separate out the impact of network performance from server performance).

Our research has found that average response times for end users can vary hugely by location, with UK-based users seeing a median response time of 365ms, and users in China sometimes seeing almost 1900ms. Some factors —the quality of a country's internet infrastructure is one of them— will always be beyond the webmaster's control, but distance alone seems to be a significant factor even now.

Median server response times by user location
Median server response times by user location

When not to worry?

Slow Times to First Byte aren’t always a cause for concern. For users, the single most important metric is the total time taken to load the page. Page load time, however, includes not only Time to First Byte, but also the time it takes to load static assets, such as CSS and Javascript. Therefore, slow TTFB doesn’t always mean slower page load time. In fact, the opposite is often true: if you choose to host certain processes server-side – as opposed to in the user’s browser – you delay the TTFB, but achieve the a faster page load time overall.

For example, static assets such as CSS files can be compressed using gzip on the server. Although this reduces overall loading time, it will typically increase the Time to First Byte, because the server has more work to do, compressing the files before they are sent out over the wire. The net result for the user might be positive, if compression means faster loading of CSS styles and JavaScript.

Depending on your application, you might choose to prepare more response data server-side—in PHP or Python, for example—rather than relying on JavaScript to fetch it in the user’s browser. If you want to ensure that the original response contains everything the user needs—and doesn’t leave them waiting on further JavaScript calls or external resources—a longer TTFB might be completely justifiable.

Does it matter for SEO?

An unfortunate misconception about Time To First Byte is that search engines treat it as a ranking factor. There is no solid evidence for this, nor does it make sense: search engines care about the user’s experience—not the time taken for the first byte to reach the browser. In addition, search engine crawlers still have some difficulty with JavaScript-heavy sites—even though those sites might have an extremely short TTFB if most of the heavy lifting takes place client-side.

Monitoring and improving TTFB

The most important thing to know about your Time To First Byte is whether it’s consistent. Even if you’re always visiting your website from your own computer or network, there’s little way to tell whether a user from Italy experienced slow page load times at 2.30am last night. So, if you want to guarantee great performance for all of your users, we’d recommend that you:

List locations

List locations

Put together a list of your most important monitoring locations — wherever your customers are liable to be (and maybe, even where they’re not).

Monitor response times

Monitor response times

Monitor site response times continuously for a few days, from all of those locations. You can do this free of charge with Server Density for 14 days — enough time to gather some data and get a sense of the scale of the problem.

Analyse Data

Analyse Data

Pull the data together with metrics gathered from your devices. Is your TTFB spiking when a particular device runs out of disk space? Is it correlated with database query times? All of the issues we’ve discussed here will have some impact, but studying your own metrics closely will help you decide which is most important for you.

When assessing the performance of your servers, Time to First Byte can be a valuable clue, helping you to focus on the metrics that matter. Start monitoring it today.

Signup takes a few seconds, setup takes a few minutes

Sign up to your now