> Basically, what it comes down to is that if all 37 requests are done in parallel, then you're only loading the page as slowly as the slowest Doesn't apply he

> Basically, what it comes down to is that if all 37 requests are done in parallel, then you're only loading the page as slowly as the slowest Doesn't apply here. Facebook is using async and downgrades the experience for mobile clients. > Most browsers will only make 6 concurrent requests from a server, which you can see in Firefox via the about:config page and the network.http.max-persistent-connections-per-server. The limitation is per host not per server. > On mobile, this means you're running 8-30 second delays for each "group" of requests, especially if you have poor reception. We are talking about an asynchronous implementation. > On the other hand, a social commenting program should need at a minimum 1 JS file, 1 CSS file, 1 for the actual data (3 comment texts, 3 base64 encoded profile pics at a small resolution). So FB is running at ~30x the optimum (87 assets, of which 35 are JS). That's the payload for the desktop clients. Furthermore, try finding a website that follows 'the optimum' standard you are describing. > If you think it's not that big a deal, I'd suggest taking a trip abroad or just out to some smaller towns in your area, and really experience why users feel the internet has not really gotten faster since the 90s (keeping in mind users don't care about data size, they care about latency). If you are still using 90's technology, you won't be able to consume most of the current websites. An asynchronous widget will not be the 'breaking point,' far from it. The scenarios you are describing will not trigger the loading of these widgets.