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?".
So, what is going on?
Expectation
Under HTTP/1.1 a good performance timeline for assets should look something like this(assuming DNS already resolved, SSL negotiated and connection established)
For small assets we would expect a short green bar with a short blue bar.
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.
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 platform is HTTP2 ready out of the box. Contact us to find out how we can help you make your site faster using HTTP2.
