3 ms·

HTTP/3 is HTTP/2 over UDP[0]. The advantage of this is that packet loss no longer delays processing of independent streams: if you lose a packet of one image it

HTTP/3 is HTTP/2 over UDP[0]. The advantage of this is that packet loss no longer delays processing of independent streams: if you lose a packet of one image it doesn't delay processing the rest of the CSS. HTTP/2 is HTTP/1.1+TLS with a custom binary encoding that allows stream multiplexing. This lets browsers download the image and the CSS over the same TCP connection without having to incur slow-start penalties every request. It's the reason why "reduce number of requests" is no longer good web dev practice. HTTP/1.1 is the usual plaintext protocol people think of when they think "HTTP". [0] Specifically a UDP overlay protocol that allows selective TCP-like delivery guarantees, called QUIC

arcbyte 4y ago
Actually I've seen more and more evidence over the past two years that even with multiplexing, reducing the number of requests is still at the top of the list in improving page speed. It's the single most impactful thing that can be done. I don't keep these bookmarked and I can't seem to find the really good one I remember seeing on HN but here's a random one: https://backlinko.com/page-speed-stats https://backlinko.com/page-speed-stats I'd say reducing the number of requests is still a very high priority practice for web devs.
- Dalewyn 4y ago
  It really doesn't (shouldn't, anyway) take an understanding of rocket science to understand why. Less requests means more bandwidth per request, means each request finishes faster (aka downloads faster), means page loads faster. Put another way, it's faster to download something smaller. Truly mindblowing, I know. Efficient use of available bandwidth will always remain a top concern, if fast page loads are a concern.
- kmeisthax 4y ago
  I may have misspoke. It's not bad advice to reduce your requests, it's just less critical. In the HTTP/1.1 days, requests were so expensive that you could drop an order of magnitude in load time by aggregating your resources. Like, to the point where if you had a big JS library that only one page used, you'd aggregate it anyway, because TCP Slow Start is a cruel mistress. Now, you'd probably want to do some measuring and comparisons first in that situation, because you might be able to get away with saving page weight on pages that don't use the library rather than aggregating it everywhere to save the request.

arcbyte 4y ago

Actually I've seen more and more evidence over the past two years that even with multiplexing, reducing the number of requests is still at the top of the list in improving page speed. It's the single most impactful thing that can be done. I don't keep these bookmarked and I can't seem to find the really good one I remember seeing on HN but here's a random one: https://backlinko.com/page-speed-stats https://backlinko.com/page-speed-stats I'd say reducing the number of requests is still a very high priority practice for web devs.

Dalewyn 4y ago
It really doesn't (shouldn't, anyway) take an understanding of rocket science to understand why. Less requests means more bandwidth per request, means each request finishes faster (aka downloads faster), means page loads faster. Put another way, it's faster to download something smaller. Truly mindblowing, I know. Efficient use of available bandwidth will always remain a top concern, if fast page loads are a concern.
kmeisthax 4y ago
I may have misspoke. It's not bad advice to reduce your requests, it's just less critical. In the HTTP/1.1 days, requests were so expensive that you could drop an order of magnitude in load time by aggregating your resources. Like, to the point where if you had a big JS library that only one page used, you'd aggregate it anyway, because TCP Slow Start is a cruel mistress. Now, you'd probably want to do some measuring and comparisons first in that situation, because you might be able to get away with saving page weight on pages that don't use the library rather than aggregating it everywhere to save the request.