HTTP/2 Benefits

So, as a developer, you might be wondering, like, why the heck should I learn HTTP/2, we had HTTP/1 for like, 20 years or something like that. It works fine, we have the tooling, we know how it works, we know how to optimize it. Well, there are five main benefits of HTTP/2, change your understanding and hopefully, I will convince you to start using HTTP/2 today. So, lets start with multiplexing. Multiplexing basically means that we have ability to handle multiple requests coming from the client to the server. So, multiple requests in a single TCP connection. That sort of eliminates the need to concatenate your assets, such as JavaScript, Prides, for images and styles.css. Now we don't get that penalty of a latency, so in some cases maybe you don't need to concatenate your 50 or 100 files into one giant file because if you have that one giant file, even a small change will invalidate your cache, the CDN cache and the browser cache, so now we can submit multiple requests at the same time. There is no penalty for submitting multiple requests and actually the web becomes faster because the browser can send multiple requests. Second benefit, it's a server push. It's a really awesome benefit and the way it works, the server can push assets, our typical CSS, JavaScript, images, whatever, before the browser even knows it needs them. That's right. So, whatever browser will need for that particular HTML page, the server can start sending out those assets and then the browser can decide oh, do I really need that resource or not? So, that translates into faster loading times and you also reduce the number of requests because server push it's not a new request. Let's see how the web works, HTTP/1 works without the server push. So number one, clients request HTML and server responds, so that's obvious. Second step, the browser takes that HTML code and it starts to render, it starts to paint the DOM, document object model. And then number three, the browser requests some additional assets, for example, in the head you would have style scripts to request CSS files and then in the body you typically will have multiple images and there you might have some fonts as well, you obviously would have some JavaScript files, so now browsers start trending more and more requests and the server has to respond to those requests and the users are waiting. And on the step five the browser finally renders the entire page with all the assets and scripts and styles and images. So, we have five steps. That's without server push. In server push scenario, we have fewer steps because the step number two, server knows HTML will need certain assets, so how does it know? Well, basically it can perform a rejects on an HTML and see all the script includes, all the CSS includes and you will see that in my code when I'm building Express middleware. And then server can push those assets while browser is still busy rendering HTML, so rendering and painting of the DOM that is one of the most time-consuming operations so that then could be utilized because we will be sending those requests from the server and then the browser, if it needs those assets, now it can pull it from the server push instead of making new requests. So, in fact, you would not have any additional requests because by now all of the assets should be on the browser. So, the browser will only use pushed assets if it needs them. So, that's really, really good in terms of security. It's exactly the same as just having script tagging your HTML. Okay, now what about the priorities? So, let's say you have that multiplex and you have multiple resources, multiple assets are coming to you, so now actually we can set up a priority, so obviously HTML has the higher priority than some CSS, so we can also control that and based on the priority, we can have some assets being processed faster then the other and then the last benefit or one of the last benefits is the header compression. So, as you know in HTTP/1 we have a lot of header information which just basically duplicates itself over and over, things like content type and etc. So, why duplicate all that when all we need is just the body? So, HTTP/2 forces all HTTP headers to be sent in a compressed format. And then the last, and I have an asterisk here because it's not a actual benefit but it's kind of implied. So, it's encryption. HTTP it's more secure because de facto all of the implementations, all of the implementations they only support HTTPS, so the browser teams they decided we not gonna support HTTP, we not gonna support the unencrypted format so now implicitly de facto we have the security in HTTPS, so the only way you can use HTTPS, meaning it would be interpreted on the client, on the browser is by using the secure connection. Okay, so too long, didn't read, old methods might not work and in some cases they might even penalize your web application. So, for example, domain sharding, that's when you will have two or more domains for different assets because there's an element of how many open connections you have on a certain domain, so a typical example, having HTTPS if you go there, they would use two sub-domains to actually deploy those assets like CSS files and images, and then the file concatenation I already spoke to you in the multiplexing so now basically it's actually a bad thing because even a small change will invalidate your cache so maybe you shouldn't concatenate files, you shouldn't create those sprites for images anymore. So, that's a quick overview. Obviously each case depends on your particular business logic, your critical applications, so don't take this as a rule set hard in stone. Obviously do your own benchmarking, do your own performance testing and decide for yourself which one of those approaches is better. Maybe you should still concatenate files. I don't know. It's still relatively new but the whole idea it's there. The browser support is there and most of the browsers Chrome, Firefox, they automatically update to the recent version, so your users have the ability, so let's tap into that potential, let's tap into HTTP/2.