In may, the IETF has finally published HTTP/2. HTTP is responsible for transferring Web pages (HTML) and its sub resources (images, CSS, JS…) from a Web server anywhere in the world to a browser anywhere else. After 16 years, this is the first update to one of the core technologies that run the Web. HTTP/1.1 was already around when most of us started to recognize the Web (while the rest of us still went to kindergarten), it was there when the Web became the revolutionary place it is now, it was there when we started to surf the Web on mobile phones, and it is still around now. So why do we need an update?
HTTP/1 was designed for a Web of text pages, where an animated GIF could give that magic touch to your site. But since then, we have allowed our design and marketing departments to put their hands on: A Web site is now much prettier, but also much heavier. Its payload has increased in orders of magnitude. (Head to the HTTP Archive for the sad truth). From today’s point of view HTTP/1 seems like running an international moving firm with a handcart. It works – with an atavistic charm – but it doesn’t scale well.
At the heart of the shortcomings of HTTP/1 is the way it utilizes TCP, the underlying Internet transport system. The preface of the standard provides a good and readable list of problems. I wont get into too much detail here. You could summarize it in one line: “Requests are expensive”, and unfortunately requests are what rich Web pages want. Every little icon, script, tracking pixel, style collection, ad banner and the such adds a penalty to your site’s performance.
But why didn’t we need HTTP/2 years ago? Well, we did! But it wasn’t there. So a collection of workarounds have been invented that have laid out the core of what we now call FEO. Today, for a Web developer it is business as usual to concatenate CSS and JS code into single big files, to fiddle with image sprites, to include (and repeat) small code directly in the HTML instead of having it in separate files. It feels normal, but it’s all workarounds! It shouldn’t be that way.
Today’s Web sites are vast, complex systems that are changed at a fast pace and are expected to perform well – both in means of speed and value. Maintainability is key to handle such systems. Add performance workarounds and their side-effects and stir well… then cook your developers until they are done. HTTP/2 solves the root cause of many performance workarounds. Costs for HTTP requests are very low, artificial delays are removed (“head-of-line blocking”), network utilization is better (so you can actually use your beloved bandwidth), caching becomes easier (as Web assets stay discrete), the upload payload is reduced (by compressing headers) which suits asynchronous Internet connections well.
That sounds great! But do we get it for free? Yes and no. On the one hand, HTTP/2 is already here. Many browsers already have HTTP/2 support, like Google Chrome, Mozilla Firefox or Microsoft Edge. Google is already serving a significant part of their traffic over HTTP/2. Akamai offers HTTP/2 on its edge servers, and work is under way to support HTTP/2 in all major Web servers and load balancers like nginx, Apache httpd, HAProxy, F5 BigIP. The list is long.
The other good news is, that HTTP/2 was carefully designed to not break the Web. It works in “Internet 1”. You don’t need new servers, routers, wires or whatnot. But compatibility comes at a price. Being able to change the means of transport through existing infrastructure, everything that could disturb the communication have to be locked out. HTTP/2 does this by (effectively) requiring an encrypted TLS connection (speak SSL). With this caveat (that on the upside makes the Web a safer place) you can use HTTP/2 now.
So, can you cross FEO measures from your todo list? Unfortunately, not yet. The Web is in a constant state of flux, and HTTP/2 adds another fraction to the fragmentation. While HTTP/2 is believed to proliferate quickly and widely, it will take ages for HTTP/1 clients to vanish. Again, we find ourselves in a transition period, until the value generated by older clients becomes negligible.
That does not only mean, that you still have to implement FEO measures for HTTP/1 clients. The protocol version is negotiated at run time. If you do your optimizations at build time, you prevent HTTP/2 from being effective. More complicated performance workarounds like domain sharding may even hurt the performance for HTTP/2 clients. On the other hand, HTTP/2 offers tools to further improve your site’s performance like Server Push or request prioritization. They want special care, too.
HTTP/2 is effectively limited to HTTPS-only sites. That comes with further implications: HTTPS renders Web proxies unusable. That also applies to your CDN, unless you pay for offloading TLS traffic on the edge (which is still quite expensive). As TCP utilization is much better in HTTP/2, you may find that page load times get better in remote areas of the world even without a CDN. However, canceling out CDNs and proxies means that your origin has to scale up in order to serve the whole traffic.
In conclusion, we now have an exciting new technology at hand to make the life of a developer easier. But for the moment it also adds to the complexity of your Web stack. We can expect HTTP/2 support to be adopted quickly. To fully leverage its power, consider using a HTTP/2 aware middleware software and definitely reach out for Web performance experts to discuss possible benefits and implications for your site.