2 is better than 1: Make way for HTTP/2
HTTP/1 has been around for ages now and remains the protocol that serves up a major percentage of web pages. So, why bother with a new version?
Picture this — Several years ago, a narrow road was built to transport a bus load of workers to a construction site and bring them back home at the end of the day. When the demands of the construction started getting complex, new ways of transporting more workers and heavier equipment on the same old road evolved and some ways were termed as “best practices” while the right thing to do was develop a better road that could take all that was needed to the construction site.
This is exactly what has happened in the http world. HTTP/1 was developed for a rather simpler world of the web. But with more complex web applications requiring more resources such as frameworks, libraries, media etc., and the devices which access the web on a wide variety of bandwidths and geographies, the page load times just can’t keep up. Best practices which are mere workarounds such as concatenating all JavaScript files, image sprites etc. have helped load pages faster, but it isn’t just fast enough.
Real pitfalls of HTTP/1
Based on Google’s research papers, an average of 100 requests are required to load up a web page. With HTTP/1, the browser can make a maximum of 6 parallel connections with the server. This results in about 16 resources per connection. Assuming an average load time of 35ms per resource, it would take about roughly 500ms to load all resources. That is half a second of waiting and doing nothing! Take in to account the fact that the browser needs to run scripts after loading, build the DOM, paint to the screen etc. — it’s going to feel like forever. If the page is accessed on a mobile device with lower bandwidths in a geography that’s half the world away from the server, it’s going to be just the recipe for user frustration.
HTTP/2 to the rescue
HTTP/2 was designed to tackle speed and security. It’s the formalized evolution of SPDY, a protocol developed by Google to improve page load speeds. It tackles security by enforcing TLS — Although the specification does not enforce, all major browser vendors dropped support for HTTP/2 without TLS thus enforcing security.
How is HTTP/2 solving the page load speed problem? For starters, instead of 6 parallel connections between the browser and the server, it sets up a single connection. I know you’re thinking, “How’s one connection in place of six making it faster?”. The secret is in how the data is loaded in one available connection that is proven to increase page load times up to 50%. Let’s look at some of the core design changes in HTTP/2 -
Header compression
HTTP headers contain a lot of information and in plain text! Cookies are one such header content that could be large and is sent and received in every communication. HTTP/2 optimizes this by
- Compressing the headers
- Passing references to headers instead of the actual headers
Just this saves on so much of redundant data being sent back and forth. Browser developer tools interpret the header and still allow you to see them in plain text. You can find a deep technical explanation on developers.google.com here.
Request / Response Multiplexing
Rather than a request waiting for a resource to be sent in full by the server and holding up the next resource request, HTTP/2 breaks down each response or a request, to smaller frames.
A single TCP connection is broken down into multiple bidirectional Streams. A stream has a unique identifier and contains multiple bidirectional Messages. Each message being a complete request or response is further broken down into frames which could simply be HTTP headers or payload and so on. Each frame contains information on which stream it belongs to.
If that was a lot to take in, just see it as disassembling data on one end of the communication and reassembling on the other end.
The benefit of this approach is the ability to keep exchanging data without having to be blocked by a previous request, a concept called Head of Line Blocking.
Server Push
Another great feature of HTTP/2 is that instead of the traditional request-response communication, the server can proactively push resources to the browser.
In the traditional communication, the browser requests for let’s say, index.html and the server returns it. Then browser then starts parsing it and realizes that it needs a certain CSS file and then requests for it. Further through the parsing, it comes across a JavaScript file and requests for it and so on.
With HTTP/2, the server can understand that if a request was made for index.html, the browser is likely going to need that CSS file and that JavaScript file and proactively pushes them thus saving the time that it takes to make additional requests.
I am an application developer — now what?
The best part with upgrading to HTTP/2 is that as an application developer, there is really nothing that you need to do. In fact, even to the extent that what you’re already doing may not be needed anymore.
Resource bundling:The whole idea of resource bundling was as a tradeoff on the size of the file in order to reduce the number of requests. Since HTTP/2 handles files differently, bundling may only prove more expensive on HTTP/2 as compared not bundling.
Obfuscation and GZIP? Definitely! We’re talking about making files as small as possible. So, the current practice of obfuscating JS files and using GZIP is still valid.
Browsers handle switching between HTTP/1 and HTTP/2: Depending on whether the server supports HTTP/1 or HTTP/2, the browser will automatically switch gears. There’s nothing to do as an application developer. Browser support for HTTP/2 can be found on caniuse
Backend Changes: Your backend can remain agnostic to the HTTP protocol like it has always been. The only change that ever needs to be made are on the web server.
Web servers: Most web servers including cloud solutions such as AWS, Google Cloud etc. Already support HTTP/2. Other popular web servers like Apache, Nginx and others can also be configured for HTTP/2. For those who are keen on knowing how this is done, this wonderful post will show you just that.
Conclusion
Research suggests that if a web page takes more than 2 seconds to load, users will have diminished interest in it. So, to meet the ever-growing demands of the internet it is very evident that web performance is key to a good user experience. HTTP/2 is a great leap forward in enabling web developers to focus on what’s delivered to their users and not on how it is delivered.
While there are many other great features in HTTP/2 such as Stream Prioritization, Flow Control and so on, the intention of this post is to give some basic familiarity to HTTP/2 and stress upon the need to start using HTTP/2. I learnt my fundamentals by reading blog posts and this wonderful intro to HTTP/2 written by Ilya Grigorik and Surma on developers.google.com
