Still not massively convinced HTTP needed to progress beyond 1.1. I’m sure someone at Google got a promotion out of it though.
Obviously one thing you can do is, for every resources spin up a new HTTP connection to the remote server. These connections have no relationship to each other, so that's a bunch of extra overhead but nevertheless your browser today will probably try to do this several times per server. Still that's pretty inadequate, surely we can do better?
So, OK, HTTP/1.1 also has keep-alive. We can re-use connections, ask for a resource, wait until that's delivered, then fetch another one.
But notice this is strictly sequential. If you're a Unix person it's natural to try the next idea for HTTP, pipelining. Don't wait until things are delivered, just ask for everything you want, surely the remote server will provide one at a time, reading your next request, serving that, then the next one and so on, right?
But for 1990s server programmers excited by threads this doesn't work. Their server has one thread gathering requests, and for each request it spawns a thread to provide the answer. If I try to pileline my HTTP requests I get muddled nonsense back from their server. Sometimes. Is that forbidden by the HTTP specification. Sure. Did it happen anyway? Yes. So your browser does not use pipelining in HTTP/1.1
Also, this suffers head-of-line blocking. If I request CreditCardStatement19960402.pdf and you must send a tape robot to retrieve that, too bad, even though I also wanted bankname.jpeg and hideousfont.css I can't retrieve those because I'm waiting for CreditCardStatement19960402.pdf. The network is idle while we wait for the robot.
Google's servers and Google's browser spoke SPDY back in the day, which fixes a bunch of this. That doesn't exist any more because HTTP/2 was standardised and has the same fixes plus other stuff, some of which proved very useful, other things not so much. Only one way to find out.
... <file1, bytes 2048-4096> <file2, bytes 0-125> ...
The server has to order critical stuff first on a pipelined connection to reduce latency but this approach can easily send stuff the client requested and will request, while collecting data serverside by any number of threads.
If you just meant, "Why didn't we ignore how the HTTP/1.1 protocol is defined and do something else?", that's not what a protocol is, you're not going to build a successful application without agreement about the protocol.