--- title: "HTTP/2 performance: you still need a bundler!" description: "Every project I deal with outdated beliefs about performance and people not really knowing about the power of HTTP/2. This video is a crash course into some of the most valuable features HTTP/2 has to offer: header compression and multiplexing." date: "2020-04-02T11:07:53.000Z" url: "https://timbenniks.dev/videos/tim/099-f5f7n2kc7hq" youtube_url: "https://www.youtube.com/watch?v=f5F7N2kc7hQ" playlist: "tim" image: "https://i.ytimg.com/vi/f5F7N2kc7hQ/maxresdefault.jpg" tags: ["composable-architecture", "performance", "frontend"] --- # HTTP/2 performance: you still need a bundler! Every project I deal with outdated beliefs about performance and people not really knowing about the power of HTTP/2. This video is a crash course into some of the most valuable features HTTP/2 has to offer: header compression and multiplexing. Watch on YouTube: https://www.youtube.com/watch?v=f5F7N2kc7hQ ## Transcript we have 220 subscribers yes this doesn't sound like a lot to most of you on YouTube but actually around 90% of all the fuse comes from subscribed users this means I have a pretty small but amazingly engaged community and this is what I wanted I wanted to put out content in a kind of a niche that people actually enjoy and properly watch so I would say goal reached but I would love to grow this a little bit because it takes a lot of effort making these videos so if I am able to monetize the videos it would be much easier for me to get new equipment and get even better content for you so please consider subscribing if you feel like it of course if you don't like it don't do it today we are talking about performance I want to talk about this because nowadays that I'm the director of web development I'm generally either on the architecture side of things or I come in later on a project if things don't go well or or if there's a fire to put out stuff like that and I guess every project I'm on we always have those KPIs which are like the goals for performance and every time our clients or our partners look into the performance they don't really kind of walk they might know but I don't really know what to say about it and they always point to things that we should fix that are actually kind of old school like nowadays there's a lot you can do for performance that goes against the rules of the old stuff so today we're talking about HTTP 2 and what it can do for performance over HTTP 1 so this is going to be a relatively short crash course that highlights a certain amount of things that I think are important that HTTP 2 gives us and then we're doing a real life test in which I in actually prove to you what you should do with HTTP 2 multiplexing header compression and stuff like that to actually make it viable in your projects let's do this [Music] alright let's dive in we are talking http/2 today that's kind of annoying isn't it this is like a 2000 joke I would say it's kind of funny I thought I'd put it in why not um okay let's start basically the things I talk about in http/2 is reducing latency so what that means is perceived speed is faster so generally what the amount of speed over the wire for HTTP is kind of fine to download the assets but actually what makes your application feel slow and sluggish is the latency towards actually starting that download and when things come back from the server so I want to talk about a couple of features today that increased the perceived speed of your website the first one is multiplexing that is a fancy word but before we go into what that is let's discuss what we use to have and then what we have now with multiplexing so in HTTP 1 this is like in the 90s beginning of the 90s and we had something called hat off line blocking what that means in this ugly-ass graph but it's it's it X illustrates is what it is anyway so you send a file on client to server saying I want this CSS file the CSS file comes back from the server and when you actually ask for another CSS file or a JavaScript file only then that can be sent and asked so it's a very synchronous operation and while you're asking for the file the browser would actually not render anything so we see a wide screen or at that time that was kind of funny right but over time we needed to be faster we couldn't wait for for people to see something right if you if you see too much of white screen people just leave your website and then we had HTTP 1.1 and they came up with something called pipelining in 1997 already so this is a long time ago so basically what that is you can actually see it's more parallel so whenever you send a file it would come back but you can have multiple files sent in parallel back in the day I guess you could send for two or two or four to one URL that would then be in parallel and then if you had another URL like static dot your domain you could ask again actually for some reason this has had a bunch of issues we're not gonna go into why that is now because there's a whole lot of story behind that but turns out that the server still has render blocking and requests when the files got a little bit bigger or when there are too many in flight it would also not work so even if you had the perfect implementation it still didn't really work so um then we got HTTP 2 and there we have something called multiplexing um as you can see this graph looks very similar to the last one only this time all the requests can be in flight all the time and it's a truly asynchronous implementation so as you can see not all of those arrows are pointing the same way and when they come back they can be faster or later it doesn't matter they can be all in flight at the same time and this really generally helps with Orman's and the next part is header compression so in each file that your request has a metadata chunk to it and that metadata says this is the date of creation this is the file type how do you want it to cache stuff like that right so an average page has like I guess 80 requests if you have like a brand website or an e-commerce stuff site like that so this is around 1,400 bytes of information if you have uncompressed raw data these bytes spread basically over multiple packets and so ATP packets and there's something in UTP called slow start which actually means you cannot send so many packets in the beginning not to saturate your connection but what that means based on those things you actually have seven or eight round trips to make you just get that header information into the browser so it knows what to do with the files that is a lot of back and forth to actually do such a basic task of seeing do I get this from the cache or not and do I understand this file type or not stuff like that so now that we compress those headers they actually fit in one packet rather than seven or eight so the UDP slow start doesn't even start up so you don't have all those round trips you only have one round trip from the the file to the to the do live server and then that's it so this is much nicer and way faster um so let's talk about bundling this is the thing we always look at right so you have the people from the old school that say and I'm one of those for a long time until recently but what that means is you bundle your files so you put them together because surfing one bigger file is actually faster and serving multiple small files this is HTTP 1.1 because we did that because the overhead of requesting a file and sending it back had a lot of like back and forward round trips needed to be able to actually load just one file but the server side of it the request the DNS all of that stuff had a lot of overhead and so what we found out if we bundled files together and only had to do that once it was actually much faster I'm in the browser to just download one thing that's a bit bigger right so in HTTP 1.1 bundling is by far the best practice and in this video I'm going to show you what it means in HTTP you to be bundling should we do it should we not do it do we have to put every NPM package we have separately as because we have multiplexing you know so the new school people would say we just put everything separately and then the old school people would say no we have to bundle them up because it's slow so right now let's go over the pros and cons of bundling itself and then after that let's do a live test to actually see what it means I'll get into what that is so bundling pros is clearly much faster with HTTP 1.1 even though there is this pipelining business also sometimes it's easier to compress bigger text files while it is let's not go into that because that's a whole different story then let's talk about the cons of bundling actually it complicates your application a little bit by now we need this as normal right we just have a bundler and it will bundle our stuff but actually when I came up we had to do that ourselves we had to code stuff back-end code to take the files compress them put them together as a lot of extra complication into Europe into your project even nowadays with those fancy react scripts and you starter kits and seal eyes all of that extra complexity is actually built in um so it's more heavy on the the smartness of your application let's say also it breaks the granular caching of your components because if you have this big file and you change only one thing you cannot just cast the rest you have to reef rebuild that file and redeliver to the user all your files so they have to invalidate that whole file and recache everything so that's kind of silly right we're so smart nowadays and we cannot actually do this properly also if a file is bigger it's slower for processing and execution if you don't have a fast processor or a lot of memory in your device it just takes longer to actually get the stuff put it in memory and execute it and then again it forces a cache invalidation for the whole file if you have a small update so let's talk about what I think is a good way to check if this HTTP to multiplexing actually work I mean if we still need bundlers so this is the demo setup I have four pages on a static metal if I innocent and they all have a different amount of files and they're all these files are different sizes so we're checking the loading time if we either load h1 with a thousand JavaScript files that are only like under a kilobyte so we're basically simulating we take every NPM package we have and we just throw it at the browser in a script tag then page two is actually 50 JavaScript files of sixteen point four kilobytes so we're basically simulating the moderate concatenation and then page three x-files of 130 6.6 kilobytes simulating aggressive concatenation and then we have page 4 with 1 J's files sorry copy mistake 820 kilobytes file really big right so we're basically simulating extreme concatenation so this is what we see a lot of the times now for HTTP 1.1 one big bundle toge is so let's have a look at the browser let's have a look at this the one file loaded in 18min a second though I'm doing this clean without cache so we might see some differences in numbers but let's see what that means so six files took 258 right again ah not 27 ok 50 files 86 a thousand files oh that's clearly longer two seconds so you could see that one six and fifty are very close together and then actually thousand is like over two seconds all right key findings time so even with HTTP two concatenation shows a significant improvement over surfing a thousand separate files so we saw that between one six or 50 files we were around between 25 milliseconds to a hundred sometimes a bit more loaded again it goes a bit down it's kind of negative negligible between the two but then when you serve a thousand separate files there's a clear delay there sir there it over saturates the bandwidth let's say so actually concluding after this test it's a small test clearly but it shows some significant things I would say we actually still need bundlers we are not yet or we might never ever been in a place where you just smack every script file of NPM you have into the browser and it just lost fast I don't think that's going to happen so we actually still meet the bundlers look at this guy we do I love this okay enough so basically concluding what you should do and what you can tell your clients and your colleagues limit the amount of concurrent streams between like a hundred twenty five and two fifty six or your whole website if you have HTTP and multiplexing in place so don't go higher than this because between different browsers you will just saturate too much surf modules in groups of similarity so they should be grouped so we do need concatenation but they should be small enough to have this cool granular cache ability so let's say your video player music player blah blah blah stuff like that is grouped so if you do an update to one of those you only have to update that file for the cache and your carousel and lazy loading images media thing is separate in another group if you don't update that it's fine right so make them small enough so you can have this granular cache but make them actually big enough to still work with HTTP 1.1 because there are people out there with all devices or all browsers that just don't support HTTP 2 or if they have maybe a flawed implementation or something so in the end it's a compromise we still need bundlers we need to bundle things in groups that are actually small enough to cache properly and to have a nice caching strategy but also to make sure that I still work with HTTP 1.1 without being too slow and that's it so it's not that hard and it's actually very interesting to learn about these things so now next time when you talk to your colleagues about performance you can actually tell them these things or if your client doesn't understand this so much or they did they want official documentation or stuff like that point them to this video and or reach out to me and then we can discuss thanks for watching and see you next time