自90年代末以来,网络浏览器DOM一直存在,但它仍然是性能/速度方面最大的限制因素之一。
我们拥有来自谷歌,Mozilla,微软,Opera,W3C以及为我们所有人开发网络技术的各种其他组织的一些世界上最杰出的人才,所以显然这不是一个简单的“哦,我们没有”优化它“问题。
我的问题如果我要处理专门针对此问题的网络浏览器,为什么我会很难让它运行得更快?
我的问题不是要求 what 让它变慢,它要求 why 没有变成快?
这似乎与其他地方的情况有关,例如性能接近C ++代码的JS引擎。
快速脚本示例:
for (var i=0;i<=10000;i++){
someString = "foo";
}
因DOM而缓慢的例子:
for (var i=0;i<=10000;i++){
element.innerHTML = "foo";
}
根据要求提供的一些细节:
在基准测试之后,看起来它不是一个无法解决的慢问题,但通常使用错误的工具,并且使用的工具取决于您跨浏览器的操作。
看起来浏览器之间的DOM效率差异很大,但我最初认为dom缓慢且无法解决的假设似乎是错误的。
我对Chrome,FF4和IE 5-9进行了测试,您可以在此图表中看到每秒的操作数:
使用DOM API时Chrome很快,但使用.innerHTML运算符的速度要慢得多(速度慢1000倍),但在某些方面,FF比Chrome差(例如,附加测试是比Chrome慢得多,但InnerHTML测试运行速度比chrome快得多。
IE似乎在使用DOM追加时变得越来越糟糕,并且随着你从5.5开始的版本更好地使用innerHTML(即IE8中的73次/秒,现在是IE9中的51次/秒)。
我在这里有测试页面:
http://jsperf.com/browser-dom-speed-tests2
有趣的是,在生成DOM时,似乎不同的浏览器似乎都面临着不同的挑战。为什么会出现这种差异?
答案 0 :(得分:47)
当您在DOM中更改某些内容时,它可能会产生无数的副作用,即重新计算布局,样式表等。
这不是唯一的原因:当你设置element.innerHTML=x
时,你不再处理普通的“存储值这里”变量,而是使用特殊对象在浏览器中更新内部状态的负载设置它们。
element.innerHTML=x
的全部含义是巨大的。粗略概述:
x
解析为HTML element
所有这些更新都必须通过一个连接Javascript和HTML引擎的API。 Javascript如此快速的一个原因是我们将它编译成更快的语言甚至是机器代码,因为值的行为是明确定义的,所以会发生大量的优化。在使用DOM API时,可以使用 none 。其他地方的加速已经让DOM落后了。
答案 1 :(得分:4)
首先,您对DOM所做的任何事情都可能是用户可见的更改。如果您更改DOM,浏览器必须再次放置所有内容。如果浏览器缓存更改,它可能会更快,然后每隔X毫秒放置一次(假设它没有这样做),但也许对这种功能没有太大的需求。
其次,innerHTML不是一个简单的操作。这是一个肮脏的黑客,MS推动,其他浏览器采用,因为它是如此有用;但它不是标准(IIRC)的一部分。使用innerHTML,浏览器必须解析字符串,并将其转换为DOM。解析很难。