Everything I didn’t know about HTTP2 (Part 1: HTTP/1.1 workarounds)
What Got You Here Won’t Get You There
Before we talk about HTTP2 we need first to know what was the problem in HTTP/1.1 that makes us need to think we need to introduce HTTP2.
When HTTP first introduced more than 20 years ago there was no intention to handle this type of rich application, AJAX…etc, and all cool stuff we have today. The most notable limitation was Head-of-line blocking, it’s a limitation which implies browser can’t issue more than 6 parallel connections per origin, it was 2 connections only in the beginning. to address this and limitation comes with it we started introducing workarounds that we’ll later name it “Best Practices™️”.
Concatenation, minification, and sprites
We have to do this as opening a new connection to download resources is a costly process and already limited (the aforementioned 6 parallel connection per origin limitation) so we will concatenate all of our assets (js, CSS and images as sprites) together and minify them to decrease the number of requests needed.
The problem with this approach is: change is costly, if you made any change for example to the minified CSS file like you change the color of the header background color, for example, you will invalidate all the CSS cache and the user will need to download this CSS file again although the change is very small compared to the change in download size. you change 6 characters and invalidate kilobytes in return for example.
Domain sharding
An interesting thing about the 6 connections limit is: it is per origin, this means if we introduce more origins(domains) we can increase the number of connections available 💡 so we started to host our assets in domains like (assets1.example.com, assets2.exmaple.com..etc). problem with this approach adding additional domain will require a new DNS lookup which the user will need to wait for before the browser can download files.
Metadata
HTTP is a stateless protocol this means we can’t know if 2 requests are by the same user or not. so we have to start using cookies; a special header that’s sent with every request we use to identify the user and may add other useful data as well. this will add additional bytes or even kilobytes to every request adding to this user agent too. the problem with this metadata is it’s static (most of the time they will be rarely changed) and not compressed data sent over the wire.
Avoidable Roundtrips
Imagine this scenario we’ve page.html hosted in our server with some assets
Although sever knows that this page.html page will request style.css, script.js, and Picaso.png files. you have no way to give a hint to the server: “when the client asks for page.html send these 3 files along with it.” although all files are on the server in the same place and it knows this HTML page will request these files.
Again we introduce a new workaround we started to inline resources, this means concatenate content of these files minify them (encode them in Base64 in case of images) so we can send them all together in the same response by writing them directly to the HTML file, this removed the need to make additional roundtrip we already know about beforehand.
But again this comes with a problem, we are sending the same data of assets over the wire again, as every time the browser requests HTML pages that uses some of the assets it has no way to utilize the idea it already receives this data before, we lost what we could gain by caching these assets. also in HTTP/1.1, we’ve no way other than cache mechanism to tell the server “we already received this data don’t send it again, please!”.
In part 2 I will talk about introducing HTTP2 and how it solves these problems, how we can start utilizing it what we need to change, and do we need to change anything, some misconceptions, and FAQ.
