What Does HTTP/2 Mean For Web Designers?

HTTP/2Last year, the HTTP/2 protocol was finalized. Support has already been implemented in Firefox and Chrome. Work is underway to integrate the protocol into web servers like Apache. It’s expected that in 2015, adoption of HTTP/2 will grow. It’s likely that adoption will proceed slowly, but it’s in the interest of web designers and developers to know what to expect.

Although most of the work towards HTTP/2 will be carried out at a lower level of the stack than web designers need to worry about — within web servers and browsers — it will have an impact on how web pages are put together. In fact, web design and front-end development habits now viewed as best practices are likely to harm performance under HTTP/2.

We’ve considered the technical changes HTTP/2 will bring here and here, so today I’d like to focus on some of the differences web designers will face in their day-to-day work.

A large proportion of what are considered performance best practices for front-end developers are actually techniques for getting around the limitations of HTTP/1.1. The earlier protocol was designed for a different web. A web page of today involves assets of many different types loaded from many different servers. For HTTP/1.1, that’s a problem, because each TCP connection will download assets one at a time, blocking further downloads until completion. So browsers open several TCP connections, each of which takes time and imposes a performance penalty, but there is a limit to how many simultaneous connections we can open to each server.

We try to work around these limitations with techniques like domain sharding, image sprites, resource inlining, and concatenation — all aimed at increasing the number of resources we can download concurrently by squeezing them down one TCP connection.

HTTP/2 will bring the gift of multiplexing: One TCP connection can request and download multiple resources concurrently. Under HTTP/2 there should never be any reason to open more than one request to a host. In fact, the HTTP/2 spec specifically warns against doing so.

In consequence, it will be largely pointless to create CSS image sprites, to join JavaScript and CSS files together into one long file, or to cram as much CSS into HTML pages as possible to avoid additional requests. HTTP requests will become much less expensive under HTTP/2. “Unbundling” has the added benefit that we will be able to send only the resources a specific page needs — only the CSS needed for page’s styles, only the images that need to display on that page.

For any reasonably complex site, the techniques we are forced to use to work around HTTP/1.1 can create a tangled mess. We can’t organize our CSS and JavaScript logically, and worst of all we are forced to cram everything together rather than have it elegantly organized so that we only send what we need. Tools like Grunt and Gulp make the process easier, but they add an extra layer of complexity to the development process. With HTTP/2 we should be able to stop worrying about the payoff between TCP connections and bandwidth and focus on creating slim web pages, organized elegantly, and sent down one “pipe”.

Matthew Davis is a technical writer and Linux geek for Future Hosting.

Dedicated Server Special

Take advantage of our Double RAM offer on the E3-1230v2 4 x 3.30GHz+HT server! Only $134.95 per month. Managed and Unmanaged options available at checkout.