为什么说 DOM 操作很慢

作者：leozdgao

网址：http://leozdgao.me/why-dom-slow/
浏览器是如何呈现一张页面的
一个浏览器有许多模块，其中负责呈现页面的是渲染引擎模块，比较熟悉的有WebKit和Gecko等，这里也只会涉及这个模块的内容。
先用文字大致阐述下这个过程：
解析HTML，并生成一棵DOM tree

解析各种样式并结合DOM tree生成一棵Render tree

对Render tree的各个节点计算布局信息，比如box的位置与尺寸

根据Render tree并利用浏览器的UI层进行绘制

其中DOM tree和Render tree上的节点并非一一对应，比如一个display:none的节点就在会存在与DOM tree上，而不会出现在Render tree上，因为这个节点不需要被绘制。




上图是Webkit的基本流程，在术语上和Gecko可能会有不同，这里贴上Gecko的流程图，不过文章下面的内容都会统一使用Webkit的术语。




影响页面呈现的因素有许多，比如link的位置会影响首屏呈现等。但这里主要集中讨论与layout相关的内容。paint是一个耗时的过程，然而layout是一个更耗时的过程，我们无法确定layout一定是自上而下或是自下而上进行的，甚至一次layout会牵涉到整个文档布局的重新计算。但是layout是肯定无法避免的，所以我们主要是要最小化layout的次数。什么情况下浏览器会进行layout在考虑如何最小化layout次数之前，要先了解什么时候浏览器会进行layout。layout（reflow）一般被称为布局，这个操作是用来计算文档中元素的位置和大小，是渲染前重要的一步。在HTML第一次被加载的时候，会有一次layout之外，js脚本的执行和样式的改变同样会导致浏览器执行layout，这也是本文的主要要讨论的内容。一般情况下，浏览器的layout是lazy的，也就是说：在js脚本执行时，是不会去更新DOM的，任何对DOM的修改都会被暂存在一个队列中，在当前js的执行上下文完成执行后，会根据这个队列中的修改，进行一次layout。然而有时希望在js代码中立刻获取最新的DOM节点信息，浏览器就不得不提前执行layout，这是导致DOM性能问题的主因。如下的操作会打破常规，并触发浏览器执行layout：通过js获取需要计算的DOM属性
添加或删除DOM元素
resize浏览器窗口大小
改变字体
css伪类的激活，比如:hover
通过js修改DOM元素样式且该样式涉及到尺寸的改变

我们来通过一个例子直观的感受下：
// Readvar h1 = element1.clientHeight; // Write (invalidates layout)element1.style.height = (h1 * 2) + 'px'; // Read (triggers layout)var h2 = element2.clientHeight; // Write (invalidates layout)element2.style.height = (h2 * 2) + 'px'; // Read (triggers layout)var h3 = element3.clientHeight; // Write (invalidates layout)element3.style.height = (h3 * 2) + 'px';
这里涉及一个属性clientHeight，这个属性是需要计算得到的，于是就会触发浏览器的一次layout。我们来利用chrome（v47.0）的开发者工具看下（截图中的timeline record已经经过筛选，仅显示layout）：





// Readvar h1 = element1.clientHeight; var h2 = element2.clientHeight; var h3 = element3.clientHeight; // Write (invalidates layout)element1.style.height = (h1 * 2) + 'px'; element2.style.height = (h2 * 2) + 'px'; element3.style.height = (h3 * 2) + 'px';看下这次的情况：




下篇再介绍一些其他的优化方案