3 ms·

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 i

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.