Sorry, this is a purely garbage comment. A "web 1.0" page with a photo gallery of a few hundred thumbnails can take a dozen seconds or more to load on my phone over 5G. Why? Because browsers limit you to six HTTP/1.1 connections each downloading a single image at a time, requested serially one after the other. A few big images? The rest of the page stops loading (regardless of the importance of the assets being loaded) until those images are done. It has nothing to do with how much bandwidth I have, it has everything to do with the insubstantial nature of HTTP/1.1 and TCP as protocols for downloading multiple files.
For literally decades, we've been jumping through hoops to avoid these problems, even on "web 1.0" sites. In 2006 when I was building web pages at a cookie cutter company, rounded corners were done with "sliding doors" because loading each corner as its own image was too slow (and border-radius hadn't been invented). Multitudes of tools to build "sprite sheets" of images that are transformed and cropped to avoid loading lots of little icons, like the file type icons on web directories of old. The "old web" sites that HN adores tend to run astoundingly badly on HTTP/1.1.
Not only do H2 and H3 fundamentally solve these _generational problems_, they've made the initial loads far faster by reducing the overhead of TLS handshakes (yet another sticking point of TLS holdouts!) and improved user privacy by encrypting more data. H2 and H3 would _absolutely_ have been welcomed with open arms fifteen years ago, long before the age of "24 fonts in 3 formats" because the problems were still present back then, regardless of whether you'd like to pretend they didn't.
We should be celebrating that these protocols made _the whole internet_ faster, not just the bloated ones that you're upset about.