Getting Ready For HTTP/2: A Guide For Web Designers And Developers
Written by Rachel Andrew / Courtesy of Smashing Magazine
The Hypertext Transfer Protocol (HTTP) is the protocol that governs the connection between your server and the browsers of your website’s visitors. For the first time since 1999, we have a new version of this protocol, and it promises far faster websites for everyone.
In this article, we’ll look at the basics of HTTP/2 as they apply to web designers and developers. I’ll explain some of the key features of the new protocol, look at browser and server compatibility, and detail the things you might need to think about as we see more adoption of HTTP/2. By reading this article, you will get an overview of what to consider changing in your workflow in the short and long term. I’ll also include plenty of resources if you want to dig further into the issues raised. My aim is to give you enough of the background to be able to make good decisions as you plan your move to HTTP/2.
A Brief History Of HTTP
HTTP is an old protocol, initially defined in 1991, with the last major revision — HTTP/1.1 — published in 1999. Websites in 1999 were very different to the websites we develop today. In http2 explained, Daniel Sternberg notes that the amount of data now required to load the home page of an average website is 1.9 MB, with over 100 individual resources required to display a page — a “resource” being anything from an image or a font to a JavaScript or CSS file.
HTTP/1.1 does not perform well when retrieving the large number of resources required to display a modern website. As we’ll see later in this article, many of the performance best practices we know as web developers come from our coping with the limitations of HTTP/1.1.
SPDY
In 2009, two engineers at Google posted about a research project they had been working on named SPDY. This project addressed some of the issues in HTTP/1.1. SPDY set out to:
- allow concurrent requests across a single TCP connection, known as multiplexing;
- allow browsers to prioritize assets so that resources vital to the display of a page could be sent by the server first;
- compress and reduce HTTP headers;
- implement server push, whereby a server can push vital resources to the browser before being asked for them.
In addition, SPDY requires an encrypted (HTTPS) connection between the browser and server.
SPDY doesn’t replace HTTP; rather, it’s a tunnel for the protocol and modifies the way existing HTTP requests and responses are sent. It requires support from both the server and the browser connecting to that server. With support available in NGINX and packages available from Google to enable support in Apache, there was a reasonable amount of adoption of SPDY. Browser support is pretty good, too, with modern versions of all major browsers supporting it.
SPDY browser support information on Can I Use.
HTTP/2
We’ve seen SPDY enjoy some success, gaining adoption with both servers and browsers. However, you might also have spotted that, despite Internet Explorer 11 being supported, Microsoft’s Edge browser has dropped it. What’s happening here?
Support for SPDY has been dropped in Edge due to Microsoft implementing support for HTTP/2, the latest version of the HTTP protocol. While other current browsers still maintain support for SPDY, Chrome will remove support in 2016, and other browsers will likely follow. At the time of writing, Edge, Firefox, Chrome and Opera support both SPDY and HTTP/2. Safari, including on iOS, will join that group later this year with the launch of Safari 9.
HTTP/2 builds on the success of SPDY, which was used as a starting point for the new protocol. As such, the majority of SPDY’s objectives are met in HTTP/2. The requirement for an HTTPS connection has been dropped. That said, all of the browser vendors have decided to only implement HTTP/2 for TLS (https) connections. So while you could potentially use HTTP/2 with clear text in server to server communications, our use case of serving HTTP/2 to browsers means that you need to have your site running on https before you can even think of moving to HTTP/2.
The HTTP/2 specification was finalized in February 2015; a year on, browser support in modern browsers is excellent. As with SPDY, HTTP/2 requires support both on the browser and server level, and there are already many web server implementations. You can keep track of these on the HTTP/2 wiki. W3Techs also has a post from July 2015 detailing adoption rates. Adoption of this protocol is happening rapidly, considering how relatively new it is.
Will We Have To Change Our Websites?
HTTP/2 is backwards-compatible with HTTP/1.1, so it would be possible to ignore it completely and everything will continue to work as before. The protocol change is completely transparent to users. Many readers of this article will have been using a protocol other than HTTP/1.1 for years. If you have a Gmail account and use Chrome to access it you will have been using SPDY and then HTTP/2 without knowing anything about it.
However, many of the things you think of as being best practices can be detrimental to performance under HTTP/2. Over time, as more servers update to use HTTP/2 and more people have browsers that support HTTP/2, your website, at one time well optimized according to best practices, will start to seem slower than websites optimized for the new protocol.
What Do We Need To Change To Embrace HTTP/2?
In the rest of this article, we’ll look at some of the common best practices that will become anti-patterns as HTTP/2 is adopted. As we’ve seen, the transition will be a slow one for many websites. To move to HTTP/2, your server software will need to be updated to support the protocol — which may be easy or almost impossible depending on how you are being hosted.
Before making changes to your website specifically for HTTP/2, you’ll also need to consider whether your visitors tend to have browsers that support it. Owners of websites that attract a lot of people using very up-to-date browsers will be able to make that switch sooner than owners whose logs show a majority of users on older browsers. To reflect this, I’ll also give you some suggestions on how to work in this transition time.
Make the Move to TLS
For a lot of websites the hardest thing about moving to HTTP/2 may not be HTTP/2 at all, but instead the requirement to run the site over a secure connection. If you are developing a new site or updating an old one your first move should be to make sure that you launch on or move to https as soon as possible. This is important not just for HTTP/2, Google uses secure connections as a ranking signal, and browsers are starting to flag non-https websites as ‘not secure’. In the future you will find that some powerful HTML5 features, such as geolocation, are unavilable without a secure connection.
If you have a site that is currently http only then my suggestion would be to prioritize a move to https first and then decide on your HTTP/2 strategy.
Continue reading the original article over at Smashing Magazine.
