Also I have read about QUIC there are some things that are interesting about it. However, there are things that I don't like.

Moreover, this was something I read from IETF mail archive: "That QUIC isn't yet proven. That's true, but the name won't be formalised or used on the wire until the RFC is published, so we have a good amount of time to back away. Even then, if it fails in the market, we can always skip to HTTP/4 one day, if we need to."[1]

I find that pretty concerning. If it does not pan out we can just skip over. That's still something someone has to implement even it's not used much. I would only be considering things that people in general are eager to use not just a few big companies.

[1] https://mailarchive.ietf.org/arch/msg/quic/RLRs4nB1lwFCZ_7k0...

Not true. This is why alpn and the upgrade header exist. You do not need to implement any of the new protocols, and you can certainly skip a version if you don't think it's worth the effort.

Having the second-largest traffic analyzer on board would seem like more of a cautionary negative than a positive to me.

If anything, smaller sites have more to gain from HTTP/2 and HTTP/3 than the likes of Google. For example:

- Both HTTP/2 and HTTP/3 seek to reduce the number of round trips, mitigating latency between the user and the server. Now, from Google's perspective, the "server" is the nearest load balancer in a globally distributed network, which is probably geographically close to wherever the user is. Thus, users with good Internet connections typically have low enough latency for the improvements not to matter much. But Google still cares about latency because of users with poor internet connections – such as anyone on a cell network in a spotty coverage area. Well, poor connections affect all sites equally. But small sites tend to not be fully distributed; they probably only have a single origin server for application logic, and perhaps a single server period, if they're not using a CDN. That means a fixed geographic location, which will have higher latency to users farther away even if they have a good connection – thus more benefit from latency mitigation.

- QUIC can send stream data in the first packet sent to the server, without having to go through a SYN/ACK handshake first. TCP Fast Open lets plain old TCP do the same thing – but only when connecting to a server you've seen in the recent past (and retrieved an authentication tag from). Thus, QUIC is faster when connecting to a server for the first time – which affects smaller sites a lot more than Google.

End users complain all the time about latency. And that includes the latency to your small website hosted on a single server hundreds of milliseconds from your visitor... certainly more than it includes google's websites.

What you really mean is that small website operators generally don't care that their visitors are irritated by how slow their website is... and just brush it off and ignore it because they have no solution to the problem.

Maybe you should consider h2 as being for the benefit of visitors across the internet, and a benefit for those who care about performance.

It says it all that even though h2 is not required, small website have adopted it across the globe... now at 1/3rd of all websites, and growing.

a. It's really cheap for us to offer that service

b. Lots of those free customers end up upgrading, paying for extras, etc.

Between a and b offering the free service makes sense. We make money from the customers who pay us for our service (https://www.cloudflare.com/plans/), not from doing something nefarious with data. We'd be shooting ourselves in the foot if we did because that data is our customers data. We need to be very careful with that or we'd lose trust and not be in business.

Also, free means anybody can try the service and kick the tires. Often those people turn out to me the CIO, CSO, CISO, CTO, ... of big corp.