Performance optimization in an HTTP/2 world

A revolution is currently going on in the underpinnings of the web. HTTP, the protocol your browser uses to connect to your site, has a new version: HTTP/2. This is not something that should concern the average user, but for web developers, it changes how we do performance optimization entirely. In this short article, I want to explain what performance optimization best practices you can do away with, and why.

What changed?

The most important thing you should know about the new HTTP/2 is that it no longer requires a new request for each file. This is the modification that makes our performance optimization guidelines change so drastically. In the HTTP1 / HTTP/1.1 world, it’d be faster to combine JS & CSS files and even images, so there would be fewer requests between browser and server. In the HTTP/2 world, this type of optimization is no longer needed and can even become counterproductive.

Can I use this already?

The answer is, fairly simply: yes. If your site is running on HTTPS, then all major current browsers support HTTP/2. You or your hosting company might have to change your server configuration to make sure it supports HTTP/2, but that’s it. Some older browsers might not be able to use it, but your site would still work for them.

So I can use HTTP/2, but should I?

Yes, you should use HTTP/2! It’s a lot faster than old fashioned HTTP1, and when you set it up well, most of your visitors will benefit hugely.

Does HTTP/2 mean I don’t need a CDN?

Even with HTTP/2 you still need a CDN. A CDN delivers content a lot faster than your average server ever will, so your site would still benefit enormously from having one. Every proper CDN will already support HTTP/2.

Performance best practices that changed

The following performance best practices are no longer needed with HTTP/2 and should be done away with:

• Concatenating CSS and JS files
  As reducing the number of requests is no longer an issue, there’s no reason to do this anymore. Minifying files is still ok.
• Image spriting
  Image spriting is the practice of combining several small images into a larger image so as to reduce the number of requests. This is a cumbersome process with quite a bit of overhead, and HTTP/2 entirely removes the need for it.
• Domain sharding
  Though this was slightly less common, some heavy sites used multiple CDN domains to serve their files. This because a browser could only open eight parallel connections to a server in the world of HTTP/1 and they’d want to serve more files in parallel. Because HTTP/2 removes the need for parallel connections as there can be parallel downloads within one connection, this best practice becomes counterproductive. The use of multiple CDN domains actually means multiple DNS requests, which slows the site down instead of speeding it up. (Steve Souders, the godfather of web performance, already predicted in 2013 that when HTTP/2 becomes ubiquitous, domain sharding will go away.)
• Inlining CSS and JS
  Inlining small bits of CSS and JS is a practice that was aggressively pushed by Google. Because the CSS and JS are inline, it cannot be cached properly. As a request for a small file now has no extra overhead, we can do away with this best practice.

Google PageSpeed and HTTP/2

Unfortunately, Google’s PageSpeed tool and many other web performance testing tools are rather slow in their adoption of HTTP/2. They should be changing their guidelines. If a simple HTTP/2 test shows you that a site is capable of using HTTP/2, quite a few of the site speed suggestions are moot. Their documentation speaks of “networking round trips” that simply, in an HTTP/2 environment, don’t happen.

There are people at Google that understand this, of course. This presentation by Ilya Gregorik in 2015 already shows all of that.

Read more: Site speed: tools and suggestions »