Akamai Diversity

The Akamai Blog

HTTP/2 Performance Monitoring

This blog post is part of an ongoing series where we discuss a wide range of topics related to HTTP/2 (h2). In today's post, I explore why TTFB (Time to First Byte) may not be the best measure of h2 performance. I also address questions regarding why TTFB may be higher for h2, and why that's not necessarily a bad thing.

Are you optimizing a website for the new h2 protocol? If so, there are some important aspects to take under consideration when establishing benchmark comparisons with sites currently optimized for HTTP version 1.1. With possible candidates popular among page measurement experts including Time to First Byte (TTFB), Time to Last Byte (TTLB), Page Load Time, DOM Loaded, DOM interactive, and more... what is the right metric to use when performance benchmarking with h2? This post specifically addresses the TTFB. Forthcoming posts will tackle the other metrics.

What is TTFB?

TTFB measures the duration between when an HTTP request is sent by the client to when it receives the first byte for the HTTP response. This does not include connection setup time, including DNS resolution, TCP connection setup time and SSL handshake time. It also does not include wait time for the connection to be available when TCP connections are reused. In the case of HTTP/1.1, connections must wait for the previous HTTP response to be received. For lack of a better metric, TTFB is often used as a measure of web-server responsiveness.  But with h2, TTFB is no longer the best proxy. 

To understand why, let's look at a couple scenarios.

HTTP/1.1 Scenario

Sarab 1.png

In this scenario, the browser opens six connections to the server, which is typical of HTTP/1.1, and sends the first six requests in parallel. After waiting for the responses to come back, if possible, it will reuse the same six connections to send the remaining requests. As seen in the legend above, TTFB (97.17ms - green color) does not include connection setup time, which is more than 50% of the total time (250.01ms).

h2 Scenario

Sarab 2.png

In the h2 example, we clearly see that h2 allows for multiplexing multiple requests using the same TCP connection. TTFB, as seen in the legend above (314.64ms - green color), is more than 80% of the total time (385.70ms). The connection setup time is typically much less for h2, as it can send the request immediately. This results in the browser/client sending all requests quickly and waiting for all the responses to arrive. This behavior may result in showing higher TTFB values for h2, because unlike HTTP/1.1, the browser/client doesn't have to wait for the connection to be set up or to become available after sending an earlier request. Even though the TTFB values are sometimes high, the total time taken for all resources is typically lower, as seen in the example above.

h2 Priorities Scenario

In addition to the timing of the requests/responses mentioned above, there is another reason why TTFB values may be higher in h2. This is the result of assigning priority weights and dependencies as explained in two previous posts (here and here). 

Let's look at a simple priority tree example in h2: 

Sarab 3.png

This tree requests that the server allot 60% of its resources for css and 40% of its resources to js at the top level. Once css is complete, it allots 50% each for image1 and image2. In the equivalent HTTP/1.1 scenario, the browser will wait for the css response to complete before sending the requests for image1 and image2. But in h2, the browser requests all four resources at once and can reasonably assume that once the css has completed, the server will allot its weight to its children, and continue to split resources between the images and js. This results in a long wait time and hence higher TTFB values for image1 and image2, as the browser has hinted it can wait for them to arrive after the css is processed. This in turn increases the mean/average TTFB values of all the objects on the page.

If not TTFB then what?

This post gives all the reasons why TTFB may not be the right measure of h2 origin/server performance. In subsequent posts we will see what metrics may provide better indications of how h2 performance compares to HTTP 1/1.

To learn more, go to: https://http2.akamai.com/

Additional reading on HTTP/2: