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.
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).