拥有许多 Shadow DOM 对浏览器性能是好是坏？

Question

Shadow DOM允许我们在文档中创建独立的 DOM 树，这些 DOM 树有自己的节点树，（或多或少）独立的样式管理，并且在某种程度上，仅“渲染”到父 DOM 树中。

我想知道大规模的性能影响。与将所有内容都放在一个大文档中相比，在一个页面上拥有许多 Shadow DOM / Shadow root 是好是坏？

一方面，我猜想，浏览器可能会受益于较小的（子）DOM 树以及在渲染仅包含实际的节点和样式的隔离 Shadow DOM 的内容时必须评估的较少的样式规则。与其内容相关。这可能会对计算工作量产生积极影响。

另一方面，在渲染时额外的“类似文档”元数据或 DOM 树的“合并”是否会减慢浏览器速度或显着增加内存使用量？

Answer 1

2022 年 6 月更新

无论有没有 Shadow DOM，DOM 树仍然是 DOM 树。独立 DOM 树的概念在浏览器级别并不真正存在。这只是概念模型。即使使用 Shadow DOM，浏览器仍然必须管理跨越 Shadow DOM 边界的样式/CSS 属性。

对于浏览器来说，渲染页面是一个多阶段的过程。在页面上使用 Shadow DOM 肯定会更好地进行样式计算。然而，浏览器的主要工作是重绘、回流和 JavaScript 执行，这些工作在相同的工作量下仍然会发生。因此，有/没有 Shadow DOM 的实际影响是理论上的。

话虽如此，无论是否使用 Shadow DOM，从性能角度来看，有两件事非常重要。首先是通过避免不必要的更改和批量 DOM 更新来最小化 DOM 访问（不读取 DOM 属性，例如强制布局重新计算的更新之间的宽度、高度）。其次是使用像样的Class或ID选择器，它们比普通元素选择器更有效。

继续同一点，您实际上可以查看CSS Containment，它实际上是一种通过允许开发人员将页面的子树与页面的其余部分隔离来提高网页性能的规范。您可以在有或没有 Shadow DOM 的情况下使用它。有人讨论过将 CSS Containment 与 Shadow DOM 结合起来，但后来什么也没发生。

简而言之，Shadow DOM 只是为 Web 应用程序提供一个隔离的（公共/私有 API）组件模型。任何性能都只是浏览器实现的一部分的副作用。而 CSS Containment 是一个向浏览器提供性能提示的官方规范。

原答案

您陷入了过早优化循环。有或没有ShadowDOM 的百万个节点并没有什么区别。

而且，如果您想考虑性能，请担心：

1. 最小化 DOM 访问 - 使用虚拟 DOM 或增量 DOM
2. 避免导致浏览器在关键循环中重流的操作
3. 避免UI/主线程上的繁重计算