我一直在与一家名为Catchpoint的公司合作，以解决我们客户端代码指标中的一些不一致之处。它们有一些事件来度量页面加载过程中的里程碑。他们为我们提供的指标是IE8。
现在，他们声称JQuery在IE中决定DOM就绪的方式实际上极大地损害了页面性能，我们应该不惜一切代价避免它。我知道JQuery用doScrollCheck()方法做了什么，在documentElement上用1ms递归setTimeout爆炸，我突然想到他们可能有一个有效的声明。
他们说每一个$(document).ready()块都会对性能造成指数级的伤害。
我的问题是，他们是否有任何统计数据来验证这种说法，如果有，我该如何实现一个ie友好的解决方案，而不重写JQuery源代码来满足我的需求。
根据JSperf的说法，多个DOM就绪函数确实会在所有浏览器中减慢页面的速度，因此我将重构大量自己的代码以适应这一新发现。当然，IE慢得令人尴尬，但测试并没有像我希望的那样提供信息，因为即使没有DOM就绪检查，它也要慢得多。这里要做的是尽可能减少使用这些DOM就绪函数。
Chrome的结果:
- 文档
- 单$()时(): 734811/秒的操作员
- 多个美元(文档)时()' s (4块): 151989/秒的操作员
- 没有美元(文档)时(): 208965555/秒的操作员
IE8的结果:
- 文档
- 单$()时(): 26349/秒的操作员
- 多个美元(文档)时()' s (4块): 5971/秒的操作员
- 没有美元(文档)时(): 5000159/秒的操作员
分析这些指标:
- 在Chrome中，没有DOM准备检查0.35%的时间一个DOM准备好了
- 在IE中，No DOM ready check占用0.53% DOM的时间准备检查需要
这个数据告诉我们doScrollCheck()函数对性能的影响相当大。
话虽如此:
- Chrome的DOM就绪检查比IE的 快27.98倍
- 在Chrome上，做4 DOM准备检查是25.45倍快比在IE
- 没有DOM就绪检查在Chrome上比IE 快41.79倍
从表面上看，这看起来毫无希望——但如果你仔细想想，没有DOM准备函数的IE页面执行了超过500万次/秒，而Chrome上单个DOM准备函数的执行次数不到100万次/秒。这告诉我，如果你设法告诉JQuery使用一个更友好的doScrollCheck()函数，说检查documentElement是否每100毫秒可滚动，而不是每1毫秒，你可能会看到页面加载时间比chrome更具竞争力。
这个基准测试真正告诉我的是，即使是DOMContentLoaded检查也慢得像地狱一样-在Chrome上从2.09亿次/秒下降到100万次以下是没有理由的。
下面的脚本测量$(document).ready()触发和正文末尾执行代码之间的时间(这是您可以操作DOM的最早时间)。你可以自己在任何浏览器上运行它。网页在这里:http://jsfiddle.net/jfriend00/dLx4L/.
我已经在jsFiddle中做了这个测试，以方便，长寿和易于分享，但如果你做了一个独立的网页，实现了同样的技术(不涉及其他框架像jsFiddle)，你可能会做一个更准确的测试。在任何情况下，您都应该能够了解如何测量它并将其付诸实际。
My 2c:
我见过很多web开发人员在页面上放了1000万javascript代码…随着最后的文档准备。
a)请记住，在一个完美的世界里，没有用户会在网页加载后立即与之交互(如图所示);和
b)在理想情况下，用户很可能在进行任何交互之前(甚至上下滚动)查看整个页面。
有了这个完美的场景，在<脚本类型…> & lt;/script>是页面的SPLASH所需的最小值，当然，也是文档准备所需的最小值。
魔法来了:把其他所有东西放在一个单独的SCRIPT.JS文件中，并在document-ready:
中使用getScript加载它$(document).ready( function () {
...
...
$.getScript('your-scripts-path/your-script-file-name.js');
});
请记住，$。当然，getScript可以成为一个dom就绪调用中的回调。而且，它也可以有回调。
祝你好运!