Of course with HTTP3, we'll get TCP out of the equation as that uses UDP/Quic underneath. If you pick the right CDN/hosting/web server, you can benefit from tha

Of course with HTTP3, we'll get TCP out of the equation as that uses UDP/Quic underneath. If you pick the right CDN/hosting/web server, you can benefit from that right now. Supported on essentially all relevant phones, browsers, etc. So, why wait? If you care about performance, upgrading your infrastructure is probably the first thing you should do, not the last thing. Mostly, the only effect of bigger download sizes is a higher chance for things to go wrong on flaky networks (e.g. on mobile) and a slight delay with the application initializing. On the first visit. The second visit, you can have all the assets cached and it matters much less. At that point the only thing slowing you down is what the application does. It's 2022. An article arguing how to get the most out of obsolete versions of HTTP (<3) and TCP seems a bit redundant as you shouldn't be using either if you can avoid it. Also, anything using less bytes than the commodore 64 that I had 40 years ago had in memory is interesting but also a bit of an exercise in being overly frugal. You should reflect on the value of your time and effort. There's a notion of diminishing returns that are very expensive. Such is the nature of optimization. Sometimes a millisecond is priceless. But mostly it's irrelevant. People have 5G and 4G phones these days capable of downloading many orders of magnitude more data per second than that. Download size is probably the wrong thing to focus on for most applications. I get it, engineers are deeply passionate about optimization and minimalism. And I appreciate what can be done with very little CSS and HTML from a technical point of view. But it's just not relevant to me on my work projects. I'd rather spend time on adding value than obsessing over saving a few kilo bytes here and there. People pay for one thing and barely even notice the other thing. I ship a quite bloated SPA to customers. It comes in around 10MB and takes a couple of seconds to get going. It's fine; it's not a problem. I could double that size and nothing would happen. Nobody would complain. We sell it for lots of money because of what it does, not because of how large or small it is. The value of halving that size is close to 0$ for us. The price of doubling the size is also close to that. The price of sacrificing features on the other hand would be a massive loss of value. Our sales team would object. And yes, we use a Google Cloud's load balancer and their CDN that does all the right things. If it mattered, I might find slightly faster options. But it just doesn't. And 10MB is actually not that bad on a decent network and nothing compared to what our application does after it loads in any case. Which would be doing lots of json API traffic, downloading map tiles and images, etc. In short, if you are not on a good network, using our app is going to suck. The initial download size would be the least of your problems in that case. And if you are on a decent network, the app loads quickly and feels very responsive. Our app simply requires a decent network. And decent networks are a widely available commodity.