Long TTFB with HTTP2 in WebPageTest

WebPageTest is a common tool that is used by us and our clients to examine site performance. It generates a beautifully detailed waterfall with great information on each request.

A common question we have been receiving lately, “The Time To First Byte for our static assets seem to be very long when using HTTPS. What is going on?”.

Long TTFB with HTTPS assets under WebPageTest.

So, what is going on?


Under HTTP/1.1 a good performance timeline for assets should look something like this(assuming DNS already resolved, SSL negotiated and connection established)

Short TTFB with HTTPS assets under WebPageTest.

For small assets we would expect a short green bar with a short blue bar.

Short TTFB with HTTPS assets under WebPageTest.

For larger assets, depending on the speed of the connection selected for the page test, we would expect a short green bar with a longer blue bar.

In both cases, the green bar which indicates Time To First Byte is very short. This is a good indicator for a fast response from the server to the browser. So why are we seeing a long green bar for HTTP2 assets? Is the server having issues processing the request? Is there network congestion? No and no, the reason is because of the way HTTP2 performs these requests and how WPT represents this graphically.

HTTP2 priorities.

Unlike HTTP/1.1 where a browser will open multiple connections each requesting a different asset, HTTP2 opens a single connection to a domain. All requests for assets from that domain are made over this connection using streams. The request for an asset is sent soon as the browser determines the asset required, it does not wait until previous assets have been received.

Most browsers will assign a priority to each stream which the server can use to determine the order of processing. Generally priorities are ordered HTML(highest), CSS(high), JS(medium), images(low). This is a simplified explanation, the priorities are actually an integer from 1 to 256(higher number == higher priority). Every browser also uses different values for priority. These values can also be effected by their dependancies, but for our purposes we will use the simplified version of the story. These priorities are hints, and the server can choose to ignore them, but if honoured it will send the assets in order of priority. This means that an asset can be requested very early in the page load, but won’t be served until higher priority asset requests have been processed. This is why it has a long TTFB.

This is in fact a good thing as prioritising critical assets such as render blocking CSS and JS before images during page load should lead to a better user experience on average. But it does lead to some very worrying looking waterfalls in some performance tests like in WebPageTest.

Longt TTFB on Facebook with WebPageTest.

Don’t worry, this is what HTTP2 can look like. The above test using Chrome on www.facebook.com is a good exampled of long TTFBs for .png and .gif files while higher priority assets are being processed.

To find out more about HTTP2 and why you should make the upgrade checkout our blog article: HTTP/2 by default

section.io platform is HTTP2 ready out of the box. Contact us to find out how we can help you make your site faster using HTTP2.

Blog Categories

Interested in articles about a specific topic? Click on a category to see all related content.

section.io Sign up

Want to get started improving your website performance, scalability, and security? Sign up for a 14 day free trial of section.io and see what we can do for you!

Get started