深入理解浏览器渲染机制：Repaint与Reflow详解及性能优化

引言：前端性能优化的核心概念

在前端开发中，资深开发者常建议避免使用CSS通配符*，限制选择器层叠深度不超过三层，优先采用类选择器，并减少HTML中使用table标签以保持DOM结构精简。过去我虽知晓通配符或过深的选择器层级会影响性能，对不使用table的原因也仅知其然不知其所以然，只是盲目遵循。直到深入了解Repaint（重绘）和Reflow（重排）机制后，才真正明白这些限制背后的性能考量。希望本文能帮助你透彻理解这些概念。

Repaint与Reflow的基本定义

1. 什么是Repaint与Reflow？

首先，通过一张图来直观展示浏览器解析的大致工作流程。

该流程图清晰展示了整个过程，可归纳为以下四个核心步骤：

1. 解析HTML构建DOM树：渲染引擎开始解析HTML文档，将HTML标签或JavaScript动态生成的标签转换为DOM节点，这被称为内容树。 2. 构建渲染树：解析CSS（包括外部CSS文件、样式元素以及JavaScript生成的样式），根据CSS选择器计算每个节点的样式，从而创建另一棵树——渲染树。 3. 布局渲染树：从根节点开始递归调用，计算每个元素的大小、位置等几何信息，确定每个节点在屏幕上出现的精确坐标。 4. 绘制渲染树：遍历渲染树，每个节点利用UI后端层进行绘制。

观察上述流程可知，Repaint和Reflow分别对应第三步和第四步。因此，我们给出如下定义：

DOM结构中每个元素都拥有自己的盒子模型，浏览器需根据各种样式（浏览器默认、开发者定义等）计算这些盒子，并将元素放置到指定位置，这一过程称为Reflow（重排）；当各盒子的位置、大小及其他属性（如颜色、字体大小等）确定后，浏览器按各自特性绘制元素，使页面内容呈现出来，这一过程称为Repaint（重绘）。 可见，这两个机制对浏览器渲染页面至关重要，且均会影响性能。因此，我们需要了解常见引发Repaint和Reflow的操作，并尽可能减少它们以提升渲染速度。

触发重绘与重排的常见操作

2. 引发Repaint和Reflow的常见操作

Reflow的性能成本远高于Repaint。DOM树中每个节点都有reflow方法，一个节点的reflow可能导致子节点、父节点甚至同级节点的reflow。在高性能电脑上可能影响不大，但在手机端，这种过程会非常痛苦且耗电。 因此，以下操作极易引发高成本的Reflow：

• 当增加、删除或修改DOM节点时，会触发Reflow或Repaint。
• 当移动DOM位置或执行动画时。
• 当修改CSS样式时。
• 当调整窗口大小（Resize，移动端通常无此问题）或滚动页面时。
• 当修改网页默认字体时。

注意：display:none会触发Reflow，而visibility:hidden仅触发Repaint，因为后者未引起位置变化。 3. 如何优化性能？

性能优化策略与最佳实践

Reflow不可避免，我们的目标是将其对性能的影响降至最低。以下是几条优化建议：

避免逐条修改DOM样式。更好的做法是预先定义好CSS的class，然后直接修改DOM的className：

 // 不好的写法
  var left = 10,
  top = 10;
  el.style.left = left + "px";
  el.style.top = top + "px";
  // 推荐写法
  el.className += " theclassname";

将DOM离线后修改。例如： a. 使用documentFragment对象在内存中操作DOM。 b. 先将DOM设置为display:none（触发一次Repaint），然后随意修改，比如修改100次，最后再将其显示出来。 c. 克隆一个DOM节点到内存中，修改完毕后，再与在线节点交换。

避免将DOM节点的属性值放在循环中作为循环变量，否则会导致大量读写该节点属性。

尽可能修改层级较低的DOM节点。当然，改变底层DOM节点可能引发大面积Reflow，但也可能影响范围很小，需视具体情况而定。

为动画涉及的HTML元素使用fixed或absolute定位，修改其CSS样式可大幅减少Reflow。

坚决避免使用table布局，因为微小的改动可能导致整个table重新布局。

了解这些机制后，你是否对浏览器原理产生了更大兴趣？后续将更新关于浏览器原理的文章，或者你可以先搜索相关资料。理解浏览器原理确实非常重要，它能帮助我们写出性能更优的网站。