@
taoche 我们做网络层面的资源加载优化，重点考虑的是2个指标：
第一是单资源加载时间，这个主要由带宽和资源大小决定，所以我们会做压缩，会开gzip，会使用缓存
第二是网络延迟，这个和资源的大小几乎没有关系，哪怕就一个TCP包，要和服务器做一次Network Roundtrip的通信，也得经受2次的网络延迟，所以我们会有Connection: keep-alive来减少TCP链接打开的次数（因为三次握手是严重受网络延迟影响的），所以我们追求文件的合并
CDN能减少网络延迟但并不能消除，另一方面网络延迟也和客户端（比如开个迅雷试试）的网络状况有很大关系，网络是前端优化领域最不可控的部分，因此一个策略就是将不可控的内容尽可能减少，合并也是受这思想影响（当然我不是说全合并了就一定是最好的）
请求优化是一个很有意思的事，比如楼主站点在我的电脑（普通的10M带宽中国电信）下，是这样加载的：
http://img3.picbed.org/uploads/2014/10/QQ20141025_1_2x.png从图里很容易能看到这些：
1. Chrome是一批次4个请求的，4个占满以后后面的请求会阻塞
2. base.js作为一个67KB的资源，同时是后面几个js的基础，所以这个67KB不加载完，其它js是不会加载的
3. 在base.js这个大家伙加载完以前，浏览器已经把其它的图片、CSS全下载完了，同时还有段时间空在那，也就是说这段时间有几ms可以用来加载其它js这个页面就能提前几ms可用
4. 因为其它资源较少都提前完成了，common.js和index.js可以并行下载，这2个不合并在网络延迟稳定的情况下不影响整站性能，但增加了一个SPOF
从图中也可以得出一些优化的结论：
1. base.js中包含seajs，但也包含了其它东西，导致它太大了，且作为了性能的瓶颈
2. 如果把seajs单独拆开来，它依旧能和base.js并行加载不会影响性能（浏览器优先下载脚本，会把图片资源滞后），同时可以让依赖seajs的common和index提前开始下载更早可用，这是一种优化策略
3. 让seajs独立出来，通过seajs的并行加载能力（其实不用也可以实现并行），再把base拆成若干个小包，比如20KB一个共3个，从图中看几乎可以和那些图片同时完成下载，浏览器不会有段时间空着没事干，这个恰恰是和“合并”相反的一种策略，但有优化的效果，所以我说了并不是全合并一定是好的
4. 图片其实能合并或用datauri，但是考虑到图片并不是SPOF型资源，在这个Network图上也不会形成瓶颈所在，所以不合并不会造成什么问题
至于你提到的“做个CDN并发远比合并JS文件来的好”我确实不明白是什么意思，在哪几方面，怎么样的数据能显示出CDN并发好于JS文件合并呢？