在我们公司，我们将每个 Javascript 文件组合成一个大的(大约 700kb，但还在不断增长)压缩和 gzip 压缩的 Javascript 文件。我正在尝试评估对每个页面使用一个大 Javascript 文件(缩小和 gzip 压缩)与使用多个 Javascript 文件(每个页面一个)之间的性能差异。
一个明显的区别是，大的 Javascript 文件在第一个页面请求加载后可以被浏览器缓存，此后几乎不会产生开销，而当使用多个 js 文件时，每个 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 的文件接收大约 700 毫秒，对于 300 kb 的文件接收大约 300 毫秒。
这种方法有意义吗？为什么不？是否有更好的方法/任何工具来执行此操作？
最佳答案
我觉得
console.time("解析时间")
和
console.timeEnd("解析时间")
为您提供比日期对象更准确的测量结果，
Article about javascript time accuracy
关于javascript - 如何测量 JavaScript 解析时间，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11453243/