JS合并的必要性分析
2015-06-30 14:53
585 查看
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
222446_bNBn_1245989.jpg (14.16 KB, 下载次数: 0)
下载附件
2015-5-27 15:02 上传
再次访问,可以看到,静态资源都已经是304,全部来自缓冲了,其中js用时58ms。
222503_iBnC_1245989.jpg (14.12 KB, 下载次数: 0)
下载附件
2015-5-27 15:02 上传
实际上这里面包含的JS文件有许多个,串行用时5434ms:
221128_hMDY_1245989.jpg (44.71 KB, 下载次数: 0)
下载附件
2015-5-27 15:02 上传
第二次访问的时间:js文件都已经是在本地缓冲了,串行用时395ms
221325_tGHg_1245989.jpg (44.17 KB, 下载次数: 0)
下载附件
2015-5-27 15:02 上传
两下做下对比:
合并为一个文件时,首次加载用时609ms,未合并为一个文件时,首次加载串行用时5434,节省时间:4825ms,时间比率为1:8.92,也就是说只有原来的11%的时间。
合并为一个文件时,缓冲后加载用时58ms,未合并为一个文件时,缓冲后加载串行用时395ms,节省时间:337ms,时间比率为15.7,也就是说只有原来的15%。
单纯从js加载方面来看,效率提升明显!
加上压缩过滤器,看看情况如何?
062113_8Gbz_1245989.jpg (12.81 KB, 下载次数: 0)
下载附件
2015-5-27 15:02 上传
可以看到,原本5M的传输量已经变为936KB,访问时间为352ms,较压缩之前访问时间,少了237ms,时间是的58%,因此,访问时间有一定提升,尤其是网络带宽只有原来的18%,这个提升还是非常显著的。
不同的访问,数据会有一些差异,会有一些变化,但是总体来看差异还是显著的。缓冲后再访问,加载的串行时间比率为 1:合并文件个数,也就是说与合并的文件个数成正比。
新又增加了CSS合并,解决了图片资源引用的问题,有图有真相:
080211_p8HC_1245989.jpg (19.58 KB, 下载次数: 0)
下载附件
2015-5-27 15:02 上传
从图中看到,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
222446_bNBn_1245989.jpg (14.16 KB, 下载次数: 0)
下载附件
2015-5-27 15:02 上传
再次访问,可以看到,静态资源都已经是304,全部来自缓冲了,其中js用时58ms。
222503_iBnC_1245989.jpg (14.12 KB, 下载次数: 0)
下载附件
2015-5-27 15:02 上传
实际上这里面包含的JS文件有许多个,串行用时5434ms:
221128_hMDY_1245989.jpg (44.71 KB, 下载次数: 0)
下载附件
2015-5-27 15:02 上传
第二次访问的时间:js文件都已经是在本地缓冲了,串行用时395ms
221325_tGHg_1245989.jpg (44.17 KB, 下载次数: 0)
下载附件
2015-5-27 15:02 上传
两下做下对比:
合并为一个文件时,首次加载用时609ms,未合并为一个文件时,首次加载串行用时5434,节省时间:4825ms,时间比率为1:8.92,也就是说只有原来的11%的时间。
合并为一个文件时,缓冲后加载用时58ms,未合并为一个文件时,缓冲后加载串行用时395ms,节省时间:337ms,时间比率为15.7,也就是说只有原来的15%。
单纯从js加载方面来看,效率提升明显!
加上压缩过滤器,看看情况如何?
062113_8Gbz_1245989.jpg (12.81 KB, 下载次数: 0)
下载附件
2015-5-27 15:02 上传
可以看到,原本5M的传输量已经变为936KB,访问时间为352ms,较压缩之前访问时间,少了237ms,时间是的58%,因此,访问时间有一定提升,尤其是网络带宽只有原来的18%,这个提升还是非常显著的。
不同的访问,数据会有一些差异,会有一些变化,但是总体来看差异还是显著的。缓冲后再访问,加载的串行时间比率为 1:合并文件个数,也就是说与合并的文件个数成正比。
新又增加了CSS合并,解决了图片资源引用的问题,有图有真相:
080211_p8HC_1245989.jpg (19.58 KB, 下载次数: 0)
下载附件
2015-5-27 15:02 上传
从图中看到,CSS都已经被合并到uiengine.uicss文件中了。
下面还有一个css没有合并,是由于这个是皮肤样式,要用来动态切换的,如果把它也合并了,就没有办法进行皮肤动态切换了。
相关文章推荐
- 使用js的ajax方法读取txt文本里面的JSON数据并追加到Html元素节点上
- js 同一种类 变色
- 菊花文javascript实现
- JavaScript获取页面宽度高度大全
- js的定时器问题
- ecshop 首页图片广告轮播修改flash改为js-方法很简洁
- javascript中filter方法
- JS更换图片
- RapidJSON 代码剖析(四):优化 Grisu
- 利用JavaScript和Google API在网页中加入地图
- gruntjs
- Newtonsoft.Json高级用法
- .net使用Newtonsoft.Json.dll解析json过程的几种特殊情况处理
- JS实现简单的图书馆享元模式实例
- JS建造者模式基本用法实例分析
- JS模式之简单的订阅者和发布者模式完整实例
- JS模式之单例模式基本用法
- js日历学习
- 201506300917_《Javascript权威指南(第六版)——类和模块、定义类三步法、定义简单类的函数 》(P200-210)
- js简单工厂模式用法实例