Shadow DOMs允许我们在我们的文档中创建独立的 DOM 树，这些树有自己的节点树，(或多或少)独立的样式管理，并且在某种程度上，只“呈现”到父 DOM 树中。
我想知道大规模的性能影响。在一个页面上有许多 Shadow DOM/Shadow roots 与将所有内容都放在一个大文档中相比是好是坏？
一方面，我猜想，浏览器可能受益于更小的(子)DOM 树和更少的样式规则，当它们呈现仅包含节点和样式的独立 Shadow DOM 的内容时，它们必须评估的样式规则更少与其内容实际相关的内容。这可能会对计算工作产生积极影响。
另一方面，额外的“类文档”元数据或渲染时 DOM 树的“合并”是否会降低浏览器速度或显着增加内存使用量？
最佳答案
2022 年 6 月更新
DOM 树仍然是有或没有 Shadow DOM 的 DOM 树。孤立的 DOM 树的概念在浏览器级别并不存在。 这只是概念模型。即使使用 Shadow DOM，浏览器仍然必须管理跨越 Shadow DOM 边界的样式/CSS 属性。
呈现页面是浏览器的多阶段过程。页面上有 Shadow DOM 对于样式计算肯定会更好。然而，浏览器工作的一大难题是重绘、回流和 JavaScript 执行，这些工作量相同时仍会发生。因此，有/没有 Shadow DOM 的实际影响是理论上的。
话虽如此，无论是否使用 Shadow DOM，从性能的角度来看，有两件重要的事情很重要。首先是通过避免不必要的更改和批处理 DOM 更新来最小化 DOM 访问(不读取 DOM prop，比如那些更新之间的宽度、高度，这会强制布局重新计算)。其次是使用合适的 Class 或 ID 选择器，它们比普通元素选择器更有效。
继续同一个点，其实可以看CSS Containment这实际上是一种通过允许开发人员将页面的子树与页面的其余部分隔离开来提高网页性能的规范。您可以在有或没有 Shadow DOM 的情况下使用它。有 some talk将 CSS Containment 与 Shadow DOM 相结合，但之后什么都没有发生。
因此，简而言之，Shadow DOM 只是为 Web 应用程序提供一个隔离的(公共(public)/私有(private) API)组件模型。作为浏览器实现的一部分，任何性能都只是副作用。而 CSS Containment 是官方规范，用于向浏览器提供性能提示。
原始答案
您陷入了过早优化 循环。百万节点有或没有 ShadowDOM 都没有区别。
而且，如果您想考虑性能，那么请担心:
- 最小化 DOM 访问 - 使用虚拟 DOM 或增量 DOM
- 避免在关键循环中导致浏览器重新流动的操作
- 避免在 UI/主线程上进行繁重计算
关于web-component - 拥有许多 Shadow DOM 对浏览器性能来说是好是坏？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/60649377/