Learning HTTP/2: A Practical Guide for Beginners

Table of Contents

Why did HTTP/2 decide to only support HTTPS?

While the common reason, and still a valid one, is that HTTP/2 wanted to support security first, there wasn't the only incentive:

The wholly practical reason is that previous experiments with WebSocket and SPDY showed that using the Upgrade header and going over port 80 (the in the clear HTTP port) resulted in a very high error rate caused by things such as interrupting proxies. Putting the requests over TLS on port 443 (the HTTPS port) resulted in a significantly lower error rate and a cleaner protocol negotiation.

The historical reasoning for splitting static assets onto their own domains

On some level I did know this but it's a good reminder that the pattern of eg; img.example.com had an actual historical use case that may no longer be valid:

In HTTP/1 the content of the request and response headers is never compressed. As the size of the headers has increased over time, it is no longer unusual to see cookie sizes larger than a single TCP packet (~1.5 KB). As a result, the cost of shuttling header information back and forth between the origin and the client may amount to measurable latency.

It was therefore a rational recommendation to set up cookie-less domains for resources that don’t rely on cookies, for instance, images.

Similarly, having multiple objects across multiple domains meant that you could get a browser to open multiple sockets at once.

The problem here being that objects being downloaded (images/CSS) may block one another so with multiple sockets open, you could download multiple objects at once.

Prior to HTTP/2, there wasn't the native ability to download requests in parallel.

A reminder about percentiles

As someone who is rubbish at statistics, it's always a good reminder

Once you have your data, look at it in terms of percentiles and not averages. None of your users are average, but some of them have better or worse experiences. Looking at the median performance will tell you that 50% of users have better (or worse) performance than that. Jumping up to the 95th or even 99th percentile shows you some of the worst experiences your users are having. Thinking about performance this way allows you to target certain segments and monitor how your changes affect them