文档对象模型（DOM）是一个独立于特定语言的应用程序接口。在浏览器中，DOM接口是以JavaScript语言实现的，通过JavaScript来操作浏览器页面中的元素，这使得DOM成为了JavaScript中重要的组成部分

在富客户端网页应用中，界面上UI的更改都是通过DOM操作实现的，并不是通过传统的刷新页面实现的。

尽管DOM提供了丰富接口供外部调用，但DOM操作的代价很高，页面前端代码的性能瓶颈也大多集中在DOM操作上，前端性能优化的一个主要的关注点就是DOM操作的优化。

DOM操作优化的总体原则是尽量减少DOM操作，尽量避免大面积的重排和重绘

• 在浏览器中，DOM的实现和ECMAScript的实现是分离的。
• 在Chrome中，使用WebKit中的WebCore处理DOM和渲染，但ECMAScript是在V8引擎中实现的，其他浏览器的情况类似。
  • 通过JavaScript代码调用DOM接口，相当于两个独立模块的交互。相比较在同一模块中的调用，这种跨模块的调用其性能损耗是很高的。

DOM操作对性能影响最大其实还是因为它导致了浏览器的重绘（repaint）和重排（reflow）

背景：为了让读者能更深刻地理解重绘和重排对性能的影响，这里需要简单叙述一下浏览器的渲染原理。

• 从下载文档到渲染页面的过程中，浏览器会通过解析HTML文档来构建DOM树，解析CSS产生CSS规则树。
• 之后根据DOM树和CSS规则树构建渲染树，在这个过程中，CSS会根据选择器匹配HTML元素。
  • 渲染树包括了每个元素的大小、边距等样式属性，渲染树中不包含隐藏元素及head元素等不可见元素。
• 最后浏览器根据元素的坐标和大小来计算每个元素的位置，并绘制这些元素到页面上。

重绘

指的是页面的某些部分要重新绘制

比如颜色或背景色的修改，元素的位置和尺寸并没有改变；

重排

指的是元素的位置或尺寸发生了改变，浏览器需要重新计算渲染树，导致渲染树的一部分或全部发生变化。

• 渲染树重新建立后，浏览器会重新绘制页面上受影响的元素。

两者比较

重排的代价比重绘的代价高很多，重绘会影响部分的元素，而重排则有可能影响全部的元素。

如下的这些DOM操作会导致重绘或重排。

1. 增加、删除和修改可见DOM元素。
2. 页面初始化的渲染。
3. 移动DOM元素。
4. 修改CSS样式去改变DOM元素的尺寸。
5. DOM元素内容改变，使得尺寸被撑大。
6. 浏览器窗口尺寸改变。
7. 浏览器窗口滚动 可以看出，这些操作都是DOM操作中比较常见的。现代浏览器会针对重排或重绘做性能优化，如把DOM操作积累一批后统一做一次重排或重绘。

• 但在有些情况下，浏览器会立即重排或重绘。
  • 例如，请求下面的DOM元素布局信息：offsetTop/Left/Width/Height、scrollTop/Left/Width/Height、clientTop/Left/Width/ Height、getComputedStyle()或 currentStyle。因为这些值都是动态计算的，所以浏览器需要尽快完成页面的绘制，然后计算返回值，从而打乱了重排或重绘的优化。

DOM操作带来的页面重绘或重排是不可避免的，但可以遵循一些最佳实践来降低由于重排或重绘带来的影响。如下是一些具体的实践方法

常见的有频繁修改DOM元素的样式 如：

这种编码方式会因为频繁更改DOM元素的样式，触发页面多次的重排或重绘

• 现代浏览器针对这种情况有性能的优化，它会合并DOM操作，但并不是所有的浏览器都存在这样的优化。 推荐的方式是把DOM操作尽量合并，如上的代码可以优化为

类似的操作还有通过innerHTML接口修改DOM元素的内容。不要直接通过此接口来拼接HTML代码，而是以字符串方式拼接好代码后，一次性赋值给DOM元素的innerHTML接口

把DOM元素从页面流中脱离或隐藏，这样处理后，只会在DOM元素脱离和添加时，或者是隐藏和显示时才会造成页面的重绘或重排，对脱离了页面布局流的DOM元素操作就不会导致页面的性能问题。

这种方式适合那些需要大批量修改DOM元素的情况，具体的方式主要有以下3种。

1. 使用文档片段

   文档片段是一个轻量级的document对象，并不会和特定的页面关联。

   通过在文档片段上进行DOM操作，可以降低DOM操作对页面性能的影响，这种方式是创建一个文档片段，并在此片段上进行必要的DOM操作，操作完成后将它附加在页面中。

   对页面性能的影响只存在于最后把文档片段附加到页面的这一步操作上。代码类似如下：

2. 通过设置DOM元素的display样式为none来隐藏元素

3. 克隆DOM元素到内存中

总结

在现代的浏览器中，因为有了DOM操作的优化，所以应用如上的方式后可能并不能明显感受到性能的改善。

但是在仍然占有市场的一些旧浏览器中，应用以上这3种编码方式则可以大幅提高页面渲染性能

把页面中具有动画效果的元素设置为绝对定位，使得元素脱离页面布局流，从而避免了页面频繁的重排，只涉及动画元素自身的重排了。

• 这种做法可以提高动画效果的展示性能。

• 如果把动画元素设置为绝对定位并不符合设计的要求，则可以在动画开始时将其设置为绝对定位，等动画结束后恢复原始的定位设置。

在很多的网站中，页面的顶部会有大幅的广告展示，一般会动画展开和折叠显示。如果不做性能的优化，这个效果的性能损耗是很明显的。使用这里提到的优化方案，则可以提高性能。

前面讨论过，获取DOM的布局信息会有性能的损耗，如果存在重复调用，最佳的做法是尽量把这些值缓存在局部变量中。考虑如下的一个示例：

如上的代码中，会在一个循环中反复取得一个元素的offsetTop值，事实上，在此代码中该元素的offsetTop值并不会变更，会存在不必要的性能损耗。

优化的方案是在循环外部取得元素的offsetTop值，相比较之前的方案，此方案只是调用了一遍元素的offsetTop值。更改后的代码如下

另外，因为取得DOM元素的布局信息会强制浏览器刷新渲染树，并且可能会导致页面的重绘或重排，所以在有大批量DOM操作时，应避免获取DOM元素的布局信息，使得浏览器针对大批量DOM操作的优化不被破坏。

• 如果需要这些布局信息，最好是在DOM操作之前就取得。考虑如下一个示例：

根据上面的介绍，代码在遇到取得DOM元素的信息时会触发页面重新计算渲染树，如上的代码会导致页面重排两次。

如果把取得DOM元素的布局信息提前，因为浏览器会优化连续的DOM操作，所以实际上只会有一次的页面重排出现，优化后的代码如下

在DOM元素上绑定事件会影响页面的性能

• 一方面，绑定事件本身会占用处理时间
• 另一方面，浏览器保存事件绑定，绑定事件也会占用内存。 页面中元素绑定的事件越多，占用的处理时间和内存就越大，性能也就相对越差
• 因此，在页面中绑定的事件越少越好。

一个优雅的手段是使用事件托管方式，即利用事件冒泡机制，只在父元素上绑定事件处理，用于处理所有子元素的事件，在事件处理函数中根据传入的参数判断事件源元素，针对不同的源元素做不同的处理。

• 这样就不需要给每个子元素都绑定事件了，管理的事件绑定数量变少了，自然性能也就提高了。
• 这种方式也有很大的灵活性，可以很方便地添加或删除子元素，不需要考虑因元素移除或改动而需要修改事件绑定。 示例代码如下:

上述代码中，只在父元素上绑定了click事件，当单击子节点时，click事件会冒泡，父节点捕获事件后通过e.target检查事件源元素并做相应的处理。

• 事件绑定方式存在浏览器兼容问题。可以用jQuery或自己封装。 例如：

---

码字不易，点赞鼓励！

部分参考《Web前端开发最佳实践》党建

---

性能优化合集快速入口：

• 如何制定前端资源的最佳缓存策略？
  • 浏览器缓存的起点 -> Cache-Control
  • 浏览器缓存机制（结合响应头）
• <link>和<script>和dom解析渲染之间的关系
  • 浏览器多进程架构简介
• 理解web性能概念以及常用分析工具
  • web性能分析工具 PageSpeed Insights 和 Lighthouse 使用教程
• web性能-白屏时间详解以及优化
  • web性能-HTML和CSS优化
  • web性能-图片优化
  • web性能-字体优化
  • web性能-js优化
  • web性能-优化dom操作（重排 重绘）
  • TCP传输基本原理简述及优化
  • web性能-CDN架构介绍和优化
    • webpack工程项目中配置第三方库的CDN，并做CDN容错
• 真实用户的前端性能监控