The HTTP/2 Landscape in 2021
When the internet first came into existence in 1983, its communication channels didn’t exist, and it was just operational enough to be used for research purposes.
In 1989, Tim Berners-Lee had the idea to develop a system for the internet using TCP/IP protocols. That public project at CERN introduced HTTP, HTML, World Wide Web (WWW), and a client–server as communication mechanisms.
In this post, you’ll learn how HTTP protocol works and how new versions brought it to where we are now, with the widely used HTTP/2 in 2021.
In the Beginning
With the first version of HTTP, or HTTP/0.9, only HTML documents could be sent. Error messages weren’t possible and neither was a status code from the server.
A plain HTML file looked like this:
GET /dashboard.html
<html>
A very simple HTML page
</html>
Images or CSS files couldn’t be fetched between client and server.
As companies began to adopt the ecosystem and the internet grew more influential, HTTP protocol capabilities grew as well. HTTP/1.1 was standardized and documented—a major iteration.
Version 1.1 removed many of the issues and ambiguities in versions 1.0 and 0.9. It added a cache-control mechanism and introduced cross-origin resource sharing (CORS) policies for security. Most of the requests on the internet use the HTTP/1.1 protocol.
Though it’s still popular, HTTP/1.1 isn’t perfect. HTTP/1.1 performs inefficiently as web applications grow ever more complex. For every minor interaction on the web, version 1.1 opens up a new connection and a response channel.
On to HTTP/2
Researchers at Google created a new SPDY (pronounced “speedy”) communication protocol in 2010 that replaced text-based protocol with binary. It demonstrated a new way of communication between client and server. Using SPDY produced huge performance gains and improvement in overall page load time.
HTTP/2 used SPDY as a basis for development, eventually replacing it entirely. The strength of HTTP/2 lies in its revised SPDY binary-based protocol, which can handle multiple request–response channels in parallel. Unlike its predecessors, HTTP/2 maintains a continuous parallel channel, listening between client and server, instead of being one way. This eliminates the need to send multiple requests at every click of a button or minor interaction on a web page.
If you were typing something on Google Sheets in HTTP/1.1, for instance, each button press would prompt a new channel to open up, creating a request–response feedback. Based on the network condition and an HTTP header, it would wait and send the Google Sheets status accordingly. With HTTP/2, the client can always “listen” to the request channel, providing feedback instantly. Think of it as always being “subscribed” to the server, constantly sending and receiving the Google Sheets status. That two-way connection is also why your document autosaves the moment you hit the close button.
Improved Web Experience
Aside from that parallel communication channel between client and server, HTTP/2 harnesses advanced algorithms for superior performance.
- HTTP/2 uses compression algorithms to reduce the size of data packets and dissect the header from the data to have finer control while fetching and receiving requests.
- HTTP/2 introduced the concept of Server Push, which loads specified resources even before the browser requests them. This is a resource optimization technique that sends a
PUSH_PROMISEfrom the server to a browser.
Here’s a simple illustration. Notice that on the left side, the browser has to explicitly request the CSS file, while on the right side, the CSS has already been loaded to be consumed by the browser. When working with even larger files and images, this technique can dramatically boost website performance.
- Multiplexing is common with HTTP/2 requests. It makes sure there are no nonblocking requests to the server in parallel to save time.
You can see in the following graphic that in the second case, HTTP/2 is making multiple requests but not necessarily waiting for HTML or CSS resources to be allocated before proceeding to the next one.
Adapting to HTTP/2
As of now, more than 96 percent of browsers support the HTTP/2 protocol. Despite such massive support, its overall usage by websites in 2021 is still under 50 percent.
While tech giants, such as Netflix, Amazon AWS, and Google Cloud, offer HTTP/2 support, overall awareness of the protocol still lacks among midsize and smaller companies as well as among developers.
One of the reasons may be a lack of web tool support. For instance, the popular API testing tool Postman still hasn’t rolled out support for HTTP/2.
Conclusion
In an age of complex web platforms that demand cutting-edge performance, developers and companies need a protocol that can support that performance. HTTP/2 has proved it can handle complex data on request–response transmission layers, overcoming the ambiguities of its previous version.
As tooling around HTTP/2 develops and matures, we should expect to see a more gradual shift from HTTP/1 to the newer protocol and more awareness among developer communities.
In the meantime, there are already some tools available for HTTP/2. Speedscale, for instance, can help you if you’re migrating your site from HTTP/1 to HTTP/2 or if you use HTTP/2 for API development. The platform uses automated traffic replays to provide integration testing and filtered, fast debugging for your APIs, helping you save on costs and development time.