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
再次访问,可以看到,静态资源都已经是304,全部来自缓冲了,其中js用时58ms。
实际上这里面包含的JS文件有许多个,串行用时5434ms:
第二次访问的时间:js文件都已经是在本地缓冲了,串行用时395ms
两下做下对比:
合并为一个文件时,首次加载用时609ms,未合并为一个文件时,首次加载串行用时5434,节省时间:4825ms,时间比率为1:8.92,也就是说只有原来的11%的时间。
合并为一个文件时,缓冲后加载用时58ms,未合并为一个文件时,缓冲后加载串行用时395ms,节省时间:337ms,时间比率为15.7,也就是说只有原来的15%。
单纯从js加载方面来看,效率提升明显!
加上压缩过滤器,看看情况如何?
可以看到,原本5M的传输量已经变为936KB,访问时间为352ms,较压缩之前访问时间,少了237ms,时间是的58%,因此,访问时间有一定提升,尤其是网络带宽只有原来的18%,这个提升还是非常显著的。
不同的访问,数据会有一些差异,会有一些变化,但是总体来看差异还是显著的。缓冲后再访问,加载的串行时间比率为 1:合并文件个数,也就是说与合并的文件个数成正比。
新又增加了CSS合并,解决了图片资源引用的问题,有图有真相:
从图中看到,CSS都已经被合并到uiengine.uicss文件中了。
下面还有一个css没有合并,是由于这个是皮肤样式,要用来动态切换的,如果把它也合并了,就没有办法进行皮肤动态切换了。
一、效率因素
一般来说,在一个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
![](http://web.j2ee.top/data/attachment/forum/201505/27/150240q94wruuwer9ttd0y.jpg)
再次访问,可以看到,静态资源都已经是304,全部来自缓冲了,其中js用时58ms。
![](http://web.j2ee.top/data/attachment/forum/201505/27/150240vofphmm6959f5xfh.jpg)
实际上这里面包含的JS文件有许多个,串行用时5434ms:
![](http://web.j2ee.top/data/attachment/forum/201505/27/150241k3bbrvbgsb5ysbh5.jpg)
第二次访问的时间:js文件都已经是在本地缓冲了,串行用时395ms
![](http://web.j2ee.top/data/attachment/forum/201505/27/150241p52t5t322wdd7x5w.jpg)
两下做下对比:
合并为一个文件时,首次加载用时609ms,未合并为一个文件时,首次加载串行用时5434,节省时间:4825ms,时间比率为1:8.92,也就是说只有原来的11%的时间。
合并为一个文件时,缓冲后加载用时58ms,未合并为一个文件时,缓冲后加载串行用时395ms,节省时间:337ms,时间比率为15.7,也就是说只有原来的15%。
单纯从js加载方面来看,效率提升明显!
加上压缩过滤器,看看情况如何?
![](http://web.j2ee.top/data/attachment/forum/201505/27/150241gzb4pwj9ubgkdbt2.jpg)
可以看到,原本5M的传输量已经变为936KB,访问时间为352ms,较压缩之前访问时间,少了237ms,时间是的58%,因此,访问时间有一定提升,尤其是网络带宽只有原来的18%,这个提升还是非常显著的。
不同的访问,数据会有一些差异,会有一些变化,但是总体来看差异还是显著的。缓冲后再访问,加载的串行时间比率为 1:合并文件个数,也就是说与合并的文件个数成正比。
新又增加了CSS合并,解决了图片资源引用的问题,有图有真相:
![](http://web.j2ee.top/data/attachment/forum/201505/27/150241krzsifbe12fsrso1.jpg)
从图中看到,CSS都已经被合并到uiengine.uicss文件中了。
下面还有一个css没有合并,是由于这个是皮肤样式,要用来动态切换的,如果把它也合并了,就没有办法进行皮肤动态切换了。