Blog

What is HTTP/2 and Why Does It Matter to Me?

Posted by in Sustainability, Web Development tagged with


HTTP/2 is the first revision of HTTP (Hyper Text Transfer Protocol) in 15 years. In the past, when web pages were simpler, loading them didn’t require that many data requests. Today’s web pages are more resource-intensive, with images, video, JavaScript and CSS.

For a long time we’ve been using best practices like CSS sprites and shared resources to reduce the number of server requests on a page, but these are just workarounds for what is an inherent problem with HTTP/1: it essentially allows only one outstanding request per TCP connection.

HTTP/2 is an attempt at modifying this rule, and for developers obsessed with performance, usability and sustainability (like everyone who works at Mightybytes), this means a lot of standard practices are about to get thrown out the window. Or are they?

In this post, Mightybytes founder Tim Frick asks one of our developers, Davo Hynds, to explain how HTTP/2 works, how it’s different from its predecessor, HTTP/1, and what its adoption will mean for developers, site owners, and web users.

Tim: Techniques like CSS Sprites, minifying JavaScript, etc. have been workarounds for improving performance on websites. Why has this historically been necessary?

Davo: For HTTP/1, best practices suggest using image sprites, minifying and compiling your CSS and JavaScript files into a single .css or .js. When you load a website, your device has to ask the server to send over any files necessary to make the page look and function the way that it should. If your page has 10 icons, 10 CSS files, and 15 JavaScript files, that means the device has to make 35 individual requests to the server. Using sprites and compiling CSS and JS means that a device can instead make just 3 requests, reducing stress on the server and speeding up the delivery of assets to your device. While it’s absolutely necessary when optimizing for performance, this means extra work for developers and can be prohibitively difficult for non-developers to set up and configure correctly.

What is the primary advantage HTTP/2 offers to the end user over its predecessor? What about for web designers and developers?

HTTP/2 generally offers huge improvements in speed over HTTP/1. While the details on exactly how to optimize performance are still being worked out, preliminary data indicates that HTTP/2 performs 15-55% faster than HTTP/1, depending on implementation. For networks with latency problems (such as those in many developing nations), these improvements are especially noticeable.

What will happen to all those workarounds once HTTP/2 becomes standard? Anything?

In some instances, some of these “best practices” will actually become less efficient. For example, let’s say you have a script on your site that finds all of the CSS files that your site loads, and combines them into a single, master CSS file. With HTTP/2’s server push feature, it will deliver all of these separate CSS files directly to the user without them having to make individual requests for each one. Not only does it figure out which files the user will need, but it can do this and deliver those files faster than a script could compile and deliver them via HTTP/1.

That said, HTTP/2 is going to be backwards-compatible with HTTP/1, meaning that everything you were doing with HTTP/1 will still function when served up via HTTP/2. Your site won’t break if it was set up with HTTP/1 in mind. You can still compile all of your CSS files into a single file and deliver it via HTTP/2 just like in HTTP/1. It just won’t be quite as fast.

How will the web development workflow be affected by HTTP/2? What will you need to do differently?

One major difference is that sites will need to be served via SSL. This isn’t a requirement, but Chrome and Firefox have both announced that they’ll only serve sites via HTTP/2 if they’re using HTTPS. And, as previously mentioned, it won’t be important anymore to compile all of your .css and .js into single files.

There are a lot of differences and improvements that don’t affect a dev’s workflow very much. For example, HTTP/2 allows for things like headers and cookies to be compressed before being sent to the user. This may also apply to other improvements like multiplexing, using a single TCP connection and server push. Once HTTP/2 does get wider adoption and implementation, we will certainly discover new ways to optimize performance that will affect a developer’s workflow.

When should website owners consider migrating their sites to the new protocol? What drives the timing for this?

Because HTTP/2 is backwards-compatible and offers such measurable improvements, site owners could benefit from switching over as soon as they can. That said, there are a few considerations first.

First and foremost, HTTP/2 adoption is growing quickly, but it probably won’t start being available for your typical site owner until the end of 2015 at the earliest. Current versions of Chrome, FireFox and Opera all support HTTP/2, but Microsoft and Apple don’t yet. Microsoft has announced that Windows Edge will support it when it gets released, and while Apple has yet to comment, I expect the next version of Safari will offer support. Servers also need to implement it. Apache, Nginx, and others are also working on their implementations on the server-side of things.

Once these implementations are demonstrated to be stable and secure, site owners will need to ask their hosting providers to implement them. They’ll also need to take other steps to optimize their site (like setting up SSL certificates to serve their site over https).

Tim Frick is the author of four books including, most recently, Designing for Sustainability: A Guide to Building Greener Digital Products and Services, from O'Reilly Media. He is @timfrick on Twitter. Mightybytes is a full-service creative firm for conscious companies and a certified B Corporation. Connect with us on Twitter or fill out our contact form.