I hear this argument a lot, and fail to be convinced. Optimizations at scale matter a lot. Let's posit that 100,000 developer-years have been spent implementing HTTP/2 and tools to interact with it. (Hopefully a great over-estimate). Let's say we have to spend all that again to move to HTTP/3. Is it worth it?
Well, per random internet stats I haven't validated, there are about 4b internet users, spending about 3h per day on the internet apiece. I could imagine 5% of that is spent on synchronous resource loading. That's about 10m/day/user - or about 28M years/year spent waiting on resources to load. A 1% savings (the minimum of CloudFlare's range) is 280k human years / year. And that's the bottom end - could be as high as 4% (1.1M years/ year), and without BBR (negatively impacting high packet loss and high throughput connections in particular).
Is "persons average time on the internet" comparable to "paid developer time"? No. A lot of that user time is timeboxed "wasted" time, in the endless content scroll. With that in mind, is it worth it overall? Probably. I've tried to estimate in favor of developers, but I still get their one-time effort paid back 2.8-11x _each year_ in user time, under unfavorable conditions. And this is growing rapidly, both in user count and time per user.
And that says nothing about the privacy benefits of encrypting headers and whatnot, which you should probably ascribe nonzero value.
This discounts the massive cost of switching to HTTP/3 . Plus, increases in internet speed would negate all the gains within a few years.
The massive switching cost of IPv6 has slowed deployment for a decade. Since it's so expensive to switch to HTTP/3, it only benefits large companies like Google. To smaller companies it's a cost.
Only 33% of the web is using HTTP/2, which came out 6 years ago. Any big gains we're talking about are many years in the future when internet speed will be maybe double what it is now. The slow adoption of HTTP/2 relative to its great benefits compared to HTTP/3 shows you how bad adoption will be.
Since 3 is single digits percent better than two, I bet adoption won't cross 20% for almost ten years. It's only going to be the FAANG'S of the world that think such as small increase in performance is worth the switching cost.
So that was kinda a rant but I don't think throwing out big numbers because so many people use the web is a strong argument. Users aren't the ones paying a large cost for a small performance increase
HTTP/1.1 is not being retired though, so I'm not sure I follow the argument about any forced switching cost for small companies. (Which I attempted to cover in my 100k estimate anyways, though you're free to dispute it). Off-the-shelf servers will implement it as an option if you want to turn it on, some clients will support it, and for the rest, status quo should hold? Not for some - e.g. firewall manufactures will presumably have to care - but the vast majority I don't really see being negatively affected by the existence of this standard.
Speed increases will presumably be consumed by continued bloat on part of publishers, as has historically happened in all tech innovations. Which might argue that it doesn't matter regardless and no optimization is ever useful, but that's both defeatist and ignores companies who do care (e.g. CloudFlare), for whom 4% probably matters now and will matter still in a decade.
I think you're seriously underestimating the number of systems that will be forced to deal with HTTP/3 if it's standardized. These days nearly everything uses HTTP. Changing HTTP is almost as big as adding another option to TCP/UDP
Everything that touches HTTP connections. Proxies, transparent proxies, web application firewalls, every network analysis and debugging tool, layer 7 load balancers.
There's probably half a million hardware firewalls out there that won't ever get a software update. As soon as http/3 is released, they're useless. The ones that can be upgraded need downtime and people time to do so. Just in firewalls this change could cost 400 million.
Realistically, the consequences of HTTP/3 will cost billions. Is 4% faster speed worth that? There's a lot of other ways to increase speed 4% without spending any money. Like turning on profile guided optimization in the browser, or just waiting a year for CPU and network speeds to increase that much.
I'm not being defeatist here, a maximum of 4% performance increase is just not very good. Nobody would switch a video or audio codec for a few percent, why is HTTP considered easier?
I say to Google: come back with something better. 20-30%? Totally worth it. If HTTP/2 is truly within 4% of optimal we should never touch it again
I hear this argument a lot, and fail to be convinced. Optimizations at scale matter a lot. Let's posit that 100,000 developer-years have been spent implementing HTTP/2 and tools to interact with it. (Hopefully a great over-estimate). Let's say we have to spend all that again to move to HTTP/3. Is it worth it?
Well, per random internet stats I haven't validated, there are about 4b internet users, spending about 3h per day on the internet apiece. I could imagine 5% of that is spent on synchronous resource loading. That's about 10m/day/user - or about 28M years/year spent waiting on resources to load. A 1% savings (the minimum of CloudFlare's range) is 280k human years / year. And that's the bottom end - could be as high as 4% (1.1M years/ year), and without BBR (negatively impacting high packet loss and high throughput connections in particular).
Is "persons average time on the internet" comparable to "paid developer time"? No. A lot of that user time is timeboxed "wasted" time, in the endless content scroll. With that in mind, is it worth it overall? Probably. I've tried to estimate in favor of developers, but I still get their one-time effort paid back 2.8-11x _each year_ in user time, under unfavorable conditions. And this is growing rapidly, both in user count and time per user.
And that says nothing about the privacy benefits of encrypting headers and whatnot, which you should probably ascribe nonzero value.