Would still be constrained to head-of-line blocking which HTTP/3 aims to solve.

HTTP/3 will not be adopted because it's a downgrade from HTTP/2 for CDN companies.

HTTP/2 has indeed massively benefitted CDNs by providing more effective capacity per buck, but UDP based 3.0/QUIC will singlehandedly destroy it, and bring it to below HTTP 1.1.

Major CDNs seem to be adopting HTTP/3 just fine:

Cloudflare: https://blog.cloudflare.com/http3-the-past-present-and-futur...

Akamai: https://developer.akamai.com/blog/2020/04/14/quick-introduct...

Fastly: https://www.fastly.com/blog/why-fastly-loves-quic-http3

Not to mention Google, which uses it a lot for regular pages and for content (eg: YouTube video).

Adoption client-side also seems to be moving quickly too. I looked at the stats for 2 of my sites and HTTP/3 is now at 60-70%, with HTTP/2 having dropped to 25-30% already.

Good for them, when they have money to spend on servers. Budget CDNs are much less happy.

That might be the case, but HTTP/3 is supported by most major CDNs and browsers. It has been adopted already.

Also, if this blog post from 2020 is correct, performance per buck isn't that bad with some teaks: https://www.fastly.com/blog/measuring-quic-vs-tcp-computatio...

I assume things have evolved since 2020.

Could you give an eli5 as to why that's the case? Or are you just throwing out a proclamation?

The solution to that is QUIC over IP, i.e. removing UDP from the stack.

Browsers implemented it, but had to drop support because proxies don't support this, so in practice it turned out to be a major source of bugs.

It was also a source of obscure bugs and DoS-level resource usage in servers and (non-browser) clients. Some servers managed to send multiple responses together or deadlocked the connection when the timing of requests or available responses was just right. Some servers would queue up responses in memory and so were prone to excess resource usage.

Also, if you had a sent request waiting behind a slow/large response, you had to decide whether or not to send an extra request on a separate connection to get the resource sooner. And when a server closed a connection after sending a response (the spec allows it for multiple reasons), it was hard to know whether it was that the server was just not accepting more requests on that connection or whether a particular request caused it and hence whether any of the waiting request(s) should be re-sent or treated as being in error.

It isn't multiplexed. You get the responses back in the same order that you request them. I actually prefer this because I use pipelining outside the browser. I do not want to have to re-ordering responses. I have never found the lack of multiplexing to make HTTP/1.1 pipelining any less useful.^1 It is still fast. HTTP/2 and HTTP/3 appear to be designed for a web of advertising, not a web where someone is using non-browser programs to efficiently request multiple files via HTTP from a single IP address.

Some browsers implemented it, at least temporarily. However the important point no one mentions is that servers implemented it, permanently. I have been using HTTP/1.1 pipelining continuously since the mid 2000's. I could not even name an httpd that does not implement support for HTTP/1.1 pipellining (no doubt some HN commenter will come up with one, but it is a rare exception to the general rule).

1. I do not need compressed HTTP headers either. I like ASCII headers as they are useful record separators for catenated HTML. I have the forward proxy configured to add useful headers that provide additional information about the connection.