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.
Comments
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.
Also, I'm sure Apple has servers in Asia.