答疑：浏览器为什么不优化 DOM 操作的性能

知乎上有人提问：

现在前端这么繁荣，为什么大家在扎堆在 JS 上做文章，搞什么 TypeScript，Deno 什么的。DOM 操作不是开销最大的么，为什么大家不把精力放到优化浏览器交互而是 JS 技术的革新上？

浏览器一直在优化 DOM 的性能啊。

框架的目标是提高开发效率，而非运行效率。况且 DOM 的性能（或者延伸到浏览器的性能）这个确实不是由社区驱动的，虽然主流几大浏览器都是开源的，但这些浏览器的开发者几乎都是商业公司。

相比 JS 而言，开发者们对于浏览器布局和渲染的关注更少。毕竟大家对 JavaScript 的关注比较多，但是对于 CSS(3) 的性能关注就比较少了。

例如 V8 的新 JS 编译器 Turbofan 以及新的解释器 Ignition 很多开发者都听说过，甚至 QuickJS，Hermes 的发布都引起了开发者们的强烈关注。但是对于 DOM 操作或者 CSS 引擎则很少有开发者关注。

其实浏览器一直在努力。如果你不信，你可以下载一个 2 年前的 Chrome 来访问一下当前页面 。

---

2005 年 HTML 规范大概 100 页。

2020 年 HTML 规范大概 800 页。

DOM 重绘

贴一张动图来看看 Chrome 对 DOM 重绘的改进。

当 Chrome 准备在屏幕上绘制像素时，它必须首先确定页面上的哪些元素需要重绘，哪些可以从上一帧的缓存中复制。在具有频繁 DOM 更改的动态页面上，会导致严重的性能问题。

Chrome 怎么改进的呢？Chrome 为每个元素生成绘制命令，通过跟踪分析这些绘制命令，以此来识别视觉上不重叠的子集。如果未修改其中一个子集，则可以直接从缓存中复制整个块，而无需进行任何其他工作。这就显著了提升了 DOM 改变后的重绘性能。

LayoutNG

我们都知道 V8 发布新的 Turbofan 编译器之后，很多原本不能优化的 js 语句也可以优化了，更重要的是 es6 发布后可能被认为是 js 非常重大的一次变革，与其在原引擎上修修补补，不如直接换新的。

同理 CSS 也随着 web 的发展而快速变更，于是 Chrome 也开发了新的布局引擎 LayoutNG。

推荐看一下 LayoutNG 的设计文档（英文）。

Composite(合成)算法也更新为了增量 CompositeAfterPaint 和 BlinkGenPropertyTrees。

结语

其实浏览器一直都在优化 DOM 的操作性能。原文链接较多，但是公众号无法链接外部文章，所以你可以点击左下角的阅读原文来阅读。

相关推荐

• 这道 CSS 题目，57% 的开发者都答错了，你会吗？
  

• 分支预测：为什么有序数组比无序数组快?
  

• ES6 在解构赋值前每次都创建一个对象吗？会加重内存回收的负担吗？

• JavaScript 引擎基础：Shapes 和 Inline Caches

• 尴尬：ES 规范对于 Math.round 的定义，根本实现不了规范

• 驳《我不是很懂 Node.js 社区的 DRY 文化》

• Node.js 新计划：使用 V8 snapshot 将启动速度提升 8 倍

• 惊爆：V8 团队的一个错误，使得整个互联网变慢

• JavaScript 工作机制：V8 引擎内部机制及如何编写优化代码的 5 个诀窍

• 一个 npm 包的坎坷“续命”之生