Concatenating JS doesn't necessarily make things faster, since (as the article mentions) modern browsers will download up to 8 assets in parallel. If JS is delivered separately, the browser doesn't have to wait for all of it to be downloaded before parsing and executing any of it--they can be parsed (and potentially executed) in parallel.
AFAIK the scripts cannot be parsed and executed in parallel since they're not explicitly async. The browser doesn't know if any of the following scripts may depend on the previous ones (think jQuery), so it just downloads them and then waits to parse and execute them in order, blocking rendering.
It's true that delivering them in parallel may in some cases reduce the actual download time, but given the small file sizes Apple is serving, the connection overhead (TCP handshake, HTTP headers, slow start, ...) just makes it worse. Most browsers (especially mobile ones) aren't even going to download more than 4-6 files at a time, since they're not using domain sharding.
>It's true that delivering them in parallel may in some cases reduce the actual download time, but given the small file sizes Apple is serving, the connection overhead (TCP handshake, HTTP headers, slow start, ...) just makes it worse. Most browsers (especially mobile ones) aren't even going to download more than 4-6 files at a time, since they're not using domain sharding.
So what I'm wondering is if you target that 4-6 connection limit, if you get all your js files to load in one connection group can you benefit from the parallel downloading while not blocking anything? Like this: http://i.imgur.com/iuriZ.png
Seems to me like the handshake issue goes away if all the connections are made at once, and you're able to cache files more efficiently. If you make a change to one or two files you can just invalidate those caches rather than the cache of your single mega file. Just some thoughts.
>The browser doesn't know if any of the following scripts may depend on the previous ones
Yes it does. That's why the way they're ordered on the page is important. If I include jQuery after I'm trying to make jQuery function calls, it won't work (in all browsers I've tested, anyway).
You didn't get my point, probably because of my terrible english :) The browser has no way of knowing in advance if a script doesn't depend on any of the previous ones, so it cannot optimize this specific case and parse/execute the script before the other ones have been executed. You can manually tell the browser to load the scripts and execute them as soon as they're ready, in no particular order, via the async attribute. If you don't, the browser is going to assume that the order is important and load them one by one.
The best advice I could ever offer on this topic is to know your audience. If you have a server in the U.S. and you have a large customer base in China you will generally be better served by fewer larger requests than several smaller requests as the latency on each request is often the biggest killer of performance.
Now, I may be wrong in this, but here's my thoughts. If the requests are asynchronous, yes, more requests will be much worse over long distances. However, as you see here http://i.imgur.com/iuriZ.png, Chrome, FF, and IE since 8 (6,7 limited to 2 connections I think) will establish multiple simultaneous connections to each domain serving assets. So what I'm saying is that the best strategy might be serving ~4 or 5 JS and CSS files, with likely to change files separated from unlikely to change files. Serving different asset groups from different domains would speed this up even more. Just some (disconnected) thoughts.
Even if it were faster in modern browsers with a high speed connection (see MartinodF's comments) it'd still be worse on high latency connections like mobile. The number of requests has a huge impact on page speed when you get 100ms+ of latency per request.
Concatenating JS doesn't make sense when you are site like Apple.
They have a lot of mini sites that are quite different from each other e.g. Store, iPad, Home Page, Support, Developer that you may access directly and which may have 90% of JS in common. So they trade off first load for subsequent visits.
