在我们公司,我们将每个Javascript文件合并为一个大的(大约700kb但正在增长)缩小和压缩的Javascript文件。我试图评估每个页面使用一个大的Javascript文件(缩小和gzip)和使用几个Javascript文件之间的性能差异,每个页面一个。
一个显而易见的区别是,浏览器在第一页请求加载后可以缓存大Javascript文件,并且在使用多个js文件时会产生很少的开销,每个文件上至少会有一个未缓存的get请求不同的页面。所以我会为较慢的连续初始页面加载交易较慢的第一个初始页面加载。
为了找出什么时候缓慢的初始页面加载(使用一个大的Javascript文件)将成为足以证明将合并文件分解为更小的文件并更改我们的构建过程的工作的问题,我想找出解析代码需要多长时间,因此我可以估计总加载和解析时间。
到目前为止,我的方法是将一个脚本标签添加到一个测试页面,该测试页面需要花费当前时间,使用Javascript附加一个大的脚本,之后再次测量时间:
var head = document.getElementsByTagName('head')[0];
var script = document.createElement('script')
script.setAttribute('type', 'text/javascript');
script.src = 'path/700kbCombineFile.js';
start_time = new Date().getTime();
head.appendChild(script);
在700kbCombineFile.js的末尾,我附上了:
console.log(new Date().getTime() - start_time)
然后我减去从firebug获得的网络传输时间,对于700 kb文件接收大约700ms,对于300 kb文件接收大约300ms。
这种方法有意义吗?为什么不?有没有更好的方法/任何工具来做这件事?
答案 0 :(得分:5)
我想
console.time("Parsetime")
和
console.timeEnd("Parsetime")
为您提供比日期对象更精确的测量,
Article about javascript time accuracy
答案 1 :(得分:2)
解析JavaScript所花费的时间在浏览器之间会有很大差异。
你所得到的是我能想到的最好的方法来衡量解析时间,然而,我会质疑这是否是判断哪种方法更有效的最佳衡量标准。
就个人而言,我会考虑从load
开始window
事件所需的时间,从请求页面时更好地衡量哪种方法去寻找。
下载页面所花费的时间非常重要,并且在第一次加载后,文件始终已经被缓存了。