Short read: How is HTTP/2 different? Should we still minify and concatenate?

Written by Christophe Limpalair on 12/29/2015

Let's keep this explanation short and sweet. I'll provide technical links so you can learn more if you're interested.

The main difference between HTTP/2 and HTTP/1 is in the framing. Framing, in a nutshell, is how a request is laid out on the wire.

That's nice, because it means we don't have to modify our website in any way. The server and client figure things out on their own without you, the developer, having to worry about it (assuming HTTP/2 is enabled on both the client and server). The only difference is how requests are sent.



With HTTP/1, a connection is negotiated with the server, and once established, the connection becomes occupied. No other request can be sent over that connection until we receive a response. This is obviously a bottleneck, so most modern browsers let you open multiple connections as a workaround. Chrome, for example, usually opens 6 connections. That means we can fetch at most 6 resources at a time.

Today's websites usually load a lot more than 6 resources, so this limitation is still an issue.

With HTTP/2, we can use one connection for multiple requests. So instead of having to open multiple connections, we can send everything over one connection. How is this possible? Short answer: Multiplexing. Requests and responses are sliced into smaller chunks called frames. Frames are tagged with an ID that connects data to the request/response. All of this means that we can have multiple messages in flight at the same time.

Nice, right? Wait until you see some of these optimizations...

HTTP/2 Optimizations

HTTP/2 has opened the door to multiple optimizations. One of those is called prioritization.

1) Prioritization lets us tell the server in what order we would like to receive assets. For example, we could request to receive main.css before we receive image.jpeg. Since CSS files block rendering, we need to get those loaded as soon as possible. With prioritization, we can achieve this result.

Here is more technical detail on how this is possible.

2) Another optimization is Server Push.

Server Push lets the server send multiple responses for one request. Why is this beneficial? Lets say you request an HTML page. This page has CSS and JavaScript files it also needs to load before rendering. With Server Push, the server already knows that your browser is going to request those assets, so it sends them back before you even ask for them!

Here's more technical detail on Server Push.

3) The last optimization I'm going to cover is HPACK compression for headers.

I'm sure you've heard about compressing the response body with gzip, but headers (like user-agent, cookies, and others) in HTTP/1 are not compressed. Cookies can be quite lengthy, and combined with other headers, they can take up a lot of unnecessary space. HTTP/2 fixes this problem with compression.

How does this compression work? Whereas HTTP/1 always sends the user-agent (which doesn't change), HTTP/2 sends it once in the first trip, and then references it as an ID during subsequent trips. This kind of optimization can save a lot of bytes over time.

So should we still minify and concatenate?

Yes, and no.

Yes for minification. Reducing the number of bytes we transfer still helps.

No for concatenation, at least to a degree. We can now send (potentially) hundreds of requests in one connection, so we don't have to bundle files together anymore. Concatenation was a way to cheat the 6-connections-open-at-one-time limit. That limit doesn't exist in HTTP/2. In fact, concatenation could be counter productive--what if you're loading a bunch of CSS that doesn't get used on a some of your pages? You're just loading extra bytes and that can slow down rendering of your page. In HTTP/1, it was often worth avoiding an extra round trip, but in HTTP/2 it probably isn't.

Of course, that doesn't mean it's a good idea to separate your scripts or CSS files into dozens of different files. From a development point of view, that could be a nightmare. But, it's no longer a performance optimization with HTTP/2.

Measure everything and see what makes sense for your app and team.

Recap

HTTP/2 has these benefits (among some others not covered here):
  • Smaller requests
  • Multiplexing
  • Prioritizing requests
  • The server is smarter about how to respond with data
  • The server has more flexibility in how it sends a response

We should still minify files to reduce the number of bytes sent across the wire.

We don't have to concatenate anymore, but it may be a good idea from a development perspective.

For more technical detail, check out this free chapter from High Performance Browser Networking.