Every time you visit a web page, your browser fetches it by requesting all the assets of the page from a web server. Since the birth of the web, this has mostly been done via HTTP/1.1.
As time has passed, and technology has evolved, and websites have become ever more complex and asset-heavy, the HTTP/1.1 protocol has increasingly come under strain, with a lot of workarounds needed for dealing with performance issues.
Web pages, as we know them today, are often stuffed with resources — such as images, text, fonts, etc. — which make them much heavier than those of the 1990s or even 2000s. Accordingly, it takes more time for them to load, so web designers and developers have come up with nifty workarounds to duck the issue. Still, it has become obvious that there's a need for an update to the HTTP protocol itself.
HTTP/2 will bring some changes to the way pages are delivered to the browser. While ordinary Internet users might not see a big difference, designers and web developers will notice quite some. This article will look at what those changes are, and how they will affect you as a proficient tech user.
How HTTP/1 Works
To fetch the web page you'd like to visit, your browser communicates with the server. They interchange messages — the browser requesting the images, fonts and other resources needed with separate requests, and the server, in its turn, sending them as responses.
As a result, the flood of data through many connections causes congestion, and the page load speed slows down. To overcome the problem of too many requests being sent, and to make the best use of HTTP/1, inventive developers have used inlining, concatenation and image spriting. Fortunately for them, puzzling over the speed of performance will largely be a thing of the past when HTTP/2 comes.
How HTTP/2 Will Work
Your browser will still send requests to a server and get responses with the assets needed for the web page to look as it should, but some nuances in between will change. HTTP/2 brings new features such as multiplexed streams, server push, header compression and binary format — each of which I'll examine in turn.
Remember the congestions caused by many connections passing the resources such as text, fonts and pictures from the server to your browser? Multiplexing eliminates this problem by making those assets into smaller parts, passing them all via one connection, and then reassembling the resources after they've reached the final destination, the browser.
Server push represents a more efficient way to deliver assets to a browser. In an HTTP/1 environment, the HTML page is sent to the browser, the browser has to parse it and decide what assets it might need, then request those assets from the server.
HTTP/2 is more proactive in this regard, sending assets that the browser is likely to need without it having to ask. These assets go to the browser's cache, and are available immediately if and when they're needed, which is a plus for performance.
In HTTP/1, every request sent has a small piece of additional data attached — HTTP headers — that describe how a browser or a server behaves. On average, browsers are able to make about six connections at once, but given that the number of connections needed to load a typical web page can be up around 100, this leaves a lot of data to be retrieved, which takes time and bandwidth.
When an HTTP/2 connection is established, all the headers are packed into one compressed block to be sent as a unity. It gets across faster, and when the transmission is finished, the header block is decoded.
Binary Instead of Textual Format
The textual format has some extra overhead and needs to be refined, while the binary one does not need any parsing. It's also a lot more compact. Additional work of a server means additional time to wait for the web page to be loaded. That is why the binary format, with its being easier to process, is a justified enhancement.
What Developers Will Be Able to Do Differently Now
Developers will no longer have to sprite images, do inlining and concatenate files, because there will be no need to reduce the number of requests on a web page. Basically, this is going to be the biggest change in their routine. However, there is more to be said about the internal changes that might somehow affect their work.
Things to Be Aware Of
Though it's not required by the actual HTTP/2 specification, most browsers supporting HTTP/2 will require HTTPS encryption. This means that, if your HTTP/2 site is not served over an encrypted connection, visitors will either have to find some other client to visit your site or miss out.
Although there's something of a push these days for sites to be served via HTTPS, this requirement by browsers has drawn criticism, and will no doubt represent a stumbling block for some considering the switch to HTTP/2. (For more tips on What HTTPS is, and how to implement it, read SitePoint's recent introduction to HTTPS.)
The web will transition painlessly for the public. The modifications and upgrades needed for the new version of the protocol to work will take place in servers and browsers. Servers will be updated over time to eventually support both protocols. Browsers supporting the new protocol will switch to HTTP/2 automatically. At the same time, the older ones will not understand it. As a developer, you'll need to know whether both your browser and the server you are using support HTTP/2 to ensure the connection will be upgraded to it.
While many are enthusiastic about HTTP/2, others, such as Poul-Henning Kamp, are not so impressed. Kamp sees HTTP/2 as “really just a grandiose name for HTTP/1.2”, and suggests that it will most likely not last long, if it takes off at all.
According to him, the new protocol does not solve actual problems, but rather concentrates too much on bandwidth. A better focus, he suggests, would be to kill cookies as a concept and replace them with a session/identity facility. That would go some way to improving privacy in a world of heightened security concerns. As it is, HTTP/2, Kamp argues, does nothing to significantly improve privacy.
See the Difference
This Akamai demo illustrates how resources are loaded concurrently in the two versions of the protocol. The first picture is loaded via HTTP/1 and six concurrent connections (if you are using Google Chrome), while the second one comes as a whole via HTTP/2 and all parts loaded simultaneously.
If you'd like to have a more profound look at how differently data is loaded through the connections in the protocols, check out this golang.org example. It lets you try different latency settings, so that you can see how data would be loaded concurrently on devices of different capacity. The longer the delay, the more visible it is that HTTP/2 wins in terms of performance.
HTTP/2 is going to come softly for ordinary users, and with a few choices to be made by those working with the web.
In general, sites will be more secure and will load faster. The protocol does not bring any cardinal changes, possibly because such changes are more difficult to implement — both technically and politically. This is why HTTP/2 will possibly not serve us that long.
The world of technology is evolving more rapidly each year, so we might need something else in a few years. My personal hope is that the next protocol will be more flexible, and braver in meeting the challenges of changing technologies.