5 ms·

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 loa

by jabart 8y ago

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.

eeeeeeeeeeeee 8y ago
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 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/ 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.
- jabart 8y ago
  These are really great documents to reference, thank you for posting them. I'm going to send them to a few dev teams I work with to share the knowledge.
acdha 8y ago
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.
- jabart 8y ago
  Most of my tests on CDNs show they are faster unless the server is hosted in Chicago for me. I have put anycast SSL termination in front of sites before that have also decreased the ssl connection handshake, which barely beats CloudFront or CloudFlare on a decent day. If I had the money I could use Akamai which I know my ISP has before it even hits the internet, no way I could make my web server faster than that. It is not a performance de-optimization. If you have 8mb of JS, sure you should break that up, but you have 8mb of JS and that is your first true problem. I aim for about 400kb or less of JS, on a marketing website it may change once a quarter, so I really don't care and they are all first time users anyway. For a web application, I also don't care because if they are mobile they need that in one request, gziped to like 40kb, so the hours it would take to optimize for the single byte changed is still a performance budget of 80ms.
  - acdha 8y ago

by jabart 8y ago

eeeeeeeeeeeee 8y ago

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 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/ 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.

jabart 8y ago
These are really great documents to reference, thank you for posting them. I'm going to send them to a few dev teams I work with to share the knowledge.

acdha 8y ago

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.

jabart 8y ago
Most of my tests on CDNs show they are faster unless the server is hosted in Chicago for me. I have put anycast SSL termination in front of sites before that have also decreased the ssl connection handshake, which barely beats CloudFront or CloudFlare on a decent day. If I had the money I could use Akamai which I know my ISP has before it even hits the internet, no way I could make my web server faster than that. It is not a performance de-optimization. If you have 8mb of JS, sure you should break that up, but you have 8mb of JS and that is your first true problem. I aim for about 400kb or less of JS, on a marketing website it may change once a quarter, so I really don't care and they are all first time users anyway. For a web application, I also don't care because if they are mobile they need that in one request, gziped to like 40kb, so the hours it would take to optimize for the single byte changed is still a performance budget of 80ms.
- acdha 8y ago