But plenty of people have high latency internet connections.
Either due to technology (Mobile network, satellite) or due to them being very far from internet exchanges and the server's they want to connect to.
Here is an example of the speed advantage on a low latency connection:
Of course with my 1gbps broadband in a capital city both are pretty much instant when doing the test: https://imagekit.io/demo/http2-vs-http1
But that's not the majority, it's not most cases. Especially if you leave a city and are on mobile internet with poor signal.
In reality, Google mostly failed to show scientific proof that HTTP/2.0 provides beneficial on typical connections - one major reasoning why even introducing QUIC in HTTP/3. A lot of "amateur benchmarks" float the net claiming HTTP/2 speed superiority, but often the measurements are flawed (not taking TCP peculiarity like congestion control into account or even including it in the analysis; classic fault is failure to disable TCP initcwnd caching or flushing the cache when doing benchmarks).
These are the two sides of complexity: It can create marvelous web applications and it can create no visible advantage.
I we're discussing whether is reasonable - 9/10 slow pages I have encountered are slow because of "content" they push on you and would add even more garbage if they could get away with it. Of the rest - most were the opposite of engineered. Tiny minority that can't be bothered to optimize - I don't mind.
You mention sites with sprites, but I would really like to see an example of a sites that are slow on HTTP<2 for good reasons, i.e. not 90% of data being ads, trackers, popups, auto-playing videos and generating content via multi-MB javascript libraries, because that's how it's done these days.
Yes, there are hacks to work around it (bundling and spritesheets), but they have other tradeoffs, like losing ~all of your cache granularity.
A great example of this happens when someone wants to query for a list of resources.
The rest way for this would be to do requests like this
get /foo/1
get /foo/2
get /foo/3
The compromise is to create endpoints that look like this
post /foo [1,2,3]
http2 fixes all that. Making parallel requests for n datapoints isn't nearly as big an issue. Those requests can be fanned out to a bunch of servers and those servers can be in charge of figuring how how much batching thing should be doing before reaching out to the DB. Making it impossible for a single client to really tank the system.
Certainly you can work around this, usually by having the service farm out work over a message bus so you don't run into the problem of a single server going down due to a big request. However, the reason those message buses work and are fast is precisely because they are similar to Http2.
All of these have major consequences for backend services. If I have a fleet of apps talking to another fleet of apps, then it matters, a LOT, if each of those apps are creating 20 TCP connections to the other fleet. Get the wrong kind of load storm and your backend will topple over.
Now, is this super scientific? No. Rather it's based on what I've seen in the field.
Http2 has a ton of benefits when doing a lot of small message communication.
The problem with HTTP 2.0 is it does not really improve the performance in real life as in Google's "real life benchmarks," it especially does not improve the situation on lossy, and throttled connections, and may actually lead to a degradation over HTTP 1.1.
The "real life benchmarks" data from Google about QUIC is put under doubt in this light.
First there was all this hype how awesome HTTP2 would be, no mention of head of line blocking. Then, several years later, lo and behold HTTP3 is hyped next, and one big motivation is that HTTP2 turned out to have a head of line blocking problem.
What on earth is going on here? Google obviously has great engineering talent and HTTP2 must have been high profile enough to not leave to a bunch of interns. So there must be more nuance to this, does anyone know the score?
The alternative to TCP head-of-line blocking is either using a separate connection per request (which was the original performance bottleneck) or using UDP (which would've been a rather big change coming from HTTP/1.1).
Now these problems are solved incrementally, and HTTP/2 plays a part in that. Which part is stupid?
And of course SCTP (nor DCCP) are usable on the general Internet.
Of course there is zero chance of this happening (for one thing, it would probably greatly increase the chances of getting broken up earlier rather than later), but it's kind of nice to imagine someone of sufficient size throwing their weight around to stop socializing costs and shake up the useable protocol stack a bit again, and retire a lot of horrible hacks and complexity in one fell swoop.
My experience so far is that in practice this rarely works out, you end up with nastier TCP level issues instead and I get the impression that this has been the actual experience with HTTP/2 as well.
In that case the stupid part would be assuming that multiplexing over TCP is a good idea, despite various cautionary tales to the contrary.
As I said, I haven't looked into this carefully so my superficial impressions might well be wrong, which is why I'd appreciate input from someone who has properly looked into it.