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.
Frequently Asked Questions (FAQs) about HTTP/2
What are the main differences between HTTP/1 and HTTP/2?
HTTP/2 is an upgrade from HTTP/1 and comes with several improvements. The most significant difference is that HTTP/2 supports multiplexing, which allows multiple requests and responses to be sent simultaneously over a single TCP connection. This is a major improvement over HTTP/1, which only allows one request per TCP connection. HTTP/2 also supports header compression, which reduces overhead and improves speed. Additionally, HTTP/2 introduces server push, a feature that allows the server to send resources to the client before they are requested, improving load times.
How does HTTP/2 improve website performance?
HTTP/2 improves website performance in several ways. Firstly, it uses multiplexing to allow multiple requests and responses to be sent simultaneously over a single TCP connection, reducing the number of connections needed and improving speed. Secondly, it uses header compression to reduce overhead and further improve speed. Lastly, it introduces server push, which allows the server to send resources to the client before they are requested, reducing load times.
What is server push in HTTP/2 and how does it work?
Server push is a feature introduced in HTTP/2 that allows the server to send resources to the client before they are requested. This is done by the server “pushing” resources into the client’s cache, so they are ready to be used when needed. This can significantly reduce load times, as the client does not need to wait for the server to respond to a request for a resource.
How does HTTP/2 handle security?
HTTP/2 does not introduce new security features, but it does encourage the use of HTTPS by making it a requirement for some features, such as server push. This means that data sent over HTTP/2 is often encrypted, providing a higher level of security than HTTP/1.
What is multiplexing in HTTP/2?
Multiplexing is a feature of HTTP/2 that allows multiple requests and responses to be sent simultaneously over a single TCP connection. This is a major improvement over HTTP/1, which only allows one request per TCP connection. Multiplexing reduces the number of connections needed, reducing overhead and improving speed.
How does HTTP/2 handle mobile devices?
HTTP/2 is designed to work well on both desktop and mobile devices. Its features, such as multiplexing and server push, can significantly improve load times on mobile devices, where network latency is often a problem. Additionally, HTTP/2’s header compression reduces overhead, which can be particularly beneficial on mobile networks where bandwidth is often limited.
Is HTTP/2 backwards compatible with HTTP/1?
Yes, HTTP/2 is designed to be backwards compatible with HTTP/1. This means that clients and servers that only support HTTP/1 can still communicate with clients and servers that support HTTP/2. However, they will not be able to take advantage of the improvements offered by HTTP/2.
How can I upgrade to HTTP/2?
Upgrading to HTTP/2 typically involves updating your web server software or switching to a hosting provider that supports HTTP/2. Once your server supports HTTP/2, clients that also support HTTP/2 will automatically use it.
What are the potential drawbacks of HTTP/2?
While HTTP/2 offers many improvements over HTTP/1, it also has potential drawbacks. For example, because HTTP/2 uses a single TCP connection for multiple requests and responses, if that connection is lost, all ongoing requests and responses are also lost. Additionally, while server push can improve load times, if not used correctly, it can also waste bandwidth by pushing resources that the client does not need.
Is HTTP/2 widely supported?
Yes, HTTP/2 is widely supported by modern web browsers and servers. However, some older browsers and servers may not support HTTP/2.