HTTP/1 should die; HTTP/2 can do everything HTTP/1 could, only faster

It's an internal dashboard, so that was a stress testing figure - afraid it wouldn't be a terribly interesting write up. It was still exciting for me, because I'd been looking for more or less flask-with-asyncio for quite some time.

Yes and no, because it is complicated. This is a fairly naive example of HTTP/2 to illustrate a point, while most websites I am called in on to optimize the load time are not built like this. This example only shaved off around 60ms for 20 requests, if your website has 20 requests to load, you have ads or you have a resource problem.

HTTP/2 spec says it should not share a connection across a host/port combo, any content you have loaded on a CDN, or a your own cdn.mydomain.com will be a separate connection. The reason CDNs are faster is because they are closer(lower latency) or it is common and already cached in your browser.

HTTP/2 still suffers from latency and TCP Window sizes, so no your 8mb website will still be slow after you enable HTTP/2, you still have to push 8mb out to the client. If you have a site loading over 80 resources, concat and minify that first before asking your server admin to turn on HTTP/2.

HTTP/1 clients gets around some network latency issues by issuing more than one TCP socket, just like SFTP clients using more than one thread. Because it is hard to overload a single socket when your latency for your ACK packets is 200ms+. If this wasn't true, Google would not be spending the time on a UDP based version of HTTP. HTTP/2

Overall, lower you content size, lower the number of requests it takes to load your initial website, THEN turn on HTTP/2.

Yep.

I haven't seen more recent studies on this, but I do remember a lot of use cases and benchmarks I read where if your user base was on high-latency or unreliable internet connections (packet loss, even minor), HTTP/2 would be slower than 1. Here is a good summary of the issue:

https://www.twilio.com/blog/2017/10/http2-issues.html

Like you mentioned, HTTP is slowly moving towards UDP instead of TCP (QUIC protocol) to combat this.

Cloudflare covers it a bit here too: https://blog.cloudflare.com/the-road-to-quic/

I'm a fan of HTTP/2, and I think most people will benefit, but I really hate these kind of posts that only highlight the best case scenario to prove a point that has wide-ranging consequences. I can go on google and type "HTTP/2 is fast" and be reaffirmed in everything I thought about HTTP/2 -- I just did -- and almost every single blog mentioned zero downsides to using HTTP/2.

You have some IE6/HTTP 1 tuning advice which is no longer necessary in there.

> The reason CDNs are faster is because they are closer(lower latency) or it is common and already cached in your browser.

Shared CDN hit rates tend to be rather low and usually slower than self-hosting unless you're requesting a LOT of resources because the DNS + TLS setup overhead are greater than the eventual savings. Opening multiple connections was useful back when you had very low limits for the number of simultaneous requests but the browsers all raised that and HTTP/2 allowing interleaved requests really tilted that into net-loss territory.

The best way to do this is to host your site behind a CDN so that initial setup cost is amortized across almost every request and you can use things like pushes for the most critical page resources.

> If you have a site loading over 80 resources, concat and minify that first before asking your server admin to turn on HTTP/2.

Similarly, this is frequently a performance de-optimization because it means that none of your resources will be processed until the entire bundle finishes streaming and the client needs to refetch the entire thing any time a single byte changes. The right way to do this is to bundle only things which change together, prioritize the ones which block rendering, and break as much as possible out into asynchronous loads so you don't need to transfer most of it before the site is functional.