《自己动手写框架》1：JS、CSS合并带来的效率提升

JS合并的必要性分析
一、效率因素
一般来说，在一个WEB工程中，需要使用大量的JS，这些JS可能来自许多提供者。
而在页面访问时，每次访问资源都要发起一个http请求，因此，即使文件已经缓冲，也需要发出一次http请求来确认文件是否被改变过。如果js个数比较少，那么没有什么问题，但是当JS文件数目比较多的时候，就会导致页面访问效率下降。如果能把所有的js都合并为一个文件，那么就可以节省几百毫秒，甚至几秒的时间，视网络状况而定。如果不需要做任何人为处理，就节省下来这些时间，无疑是相当有意义的。
二、JS引入顺序问题
如果说，效率问题还只是用户体验的问题，而JS引入顺序问题，就会导致你的页面是否可以执行的问题。我们知道，如果JS如果有依赖其它JS库，则被依赖的JS库就要放在依赖的JS库的前面，否则就会发生js错误。当引用的JS库比较小的时候，问题当然不大，但是做企业应用的时候，要用到的JS非常多，甚至在开发后期或维护期还会增加新的JS，这时稍有不慎，就会出现JS引入顺序问题。
为此，Tiny框架提供了解决方案，可以把工程中所有引用的JS资源都根据依赖关系，按顺序放在一个JS引用当中，它可以保证JS的引用顺序是正确的，同时由于所有的JS都只放入一个文件，因此，只会发出一次HTTP请求；第三提供了文件压缩传输功能，所以会保证网络传输量最小。
从下图中，可以看到，引入的js只有一个文件：uiengine.uijs，总共用时609ms

[img]http://bbs.tinygroup.org/data/attachment/forum/201505/27/150240q94wruuwer9ttd0y.jpg[/img]
再次访问，可以看到，静态资源都已经是304，全部来自缓冲了，其中js用时58ms。

[img]http://bbs.tinygroup.org/data/attachment/forum/201505/27/150240vofphmm6959f5xfh.jpg[/img]

实际上这里面包含的JS文件有许多个，串行用时5434ms：

[img]http://bbs.tinygroup.org/data/attachment/forum/201505/27/150241k3bbrvbgsb5ysbh5.jpg[/img]

第二次访问的时间：js文件都已经是在本地缓冲了，串行用时395ms

[img]http://bbs.tinygroup.org/data/attachment/forum/201505/27/150241p52t5t322wdd7x5w.jpg[/img]
两下做下对比：
合并为一个文件时，首次加载用时609ms，未合并为一个文件时，首次加载串行用时5434，节省时间：4825ms，时间比率为1:8.92，也就是说只有原来的11%的时间。

合并为一个文件时，缓冲后加载用时58ms，未合并为一个文件时，缓冲后加载串行用时395ms，节省时间：337ms，时间比率为15.7，也就是说只有原来的15%。
单纯从js加载方面来看，效率提升明显！
加上压缩过滤器，看看情况如何？

[img]http://bbs.tinygroup.org/data/attachment/forum/201505/27/150241gzb4pwj9ubgkdbt2.jpg[/img]
可以看到，原本5M的传输量已经变为936KB，访问时间为352ms，较压缩之前访问时间，少了237ms，时间是的58%，因此，访问时间有一定提升，尤其是网络带宽只有原来的18%，这个提升还是非常显著的。
不同的访问，数据会有一些差异，会有一些变化，但是总体来看差异还是显著的。缓冲后再访问，加载的串行时间比率为 1:合并文件个数，也就是说与合并的文件个数成正比。
新又增加了CSS合并，解决了图片资源引用的问题，有图有真相：
[img]http://bbs.tinygroup.org/data/attachment/forum/201505/27/150241krzsifbe12fsrso1.jpg[/img]

从图中看到，CSS都已经被合并到uiengine.uicss文件中了。
下面还有一个css没有合并，是由于这个是皮肤样式，要用来动态切换的，如果把它也合并了，就没有办法进行皮肤动态切换了。