“现代”浏览器一次可以“处理”多少 HTML 元素？

Question

“现代”，因为该定义可能会随着时间而改变（特别是我指的是桌面浏览器）

“handle”，因为它可能因机器配置/内存而异，但我指的是一般用例。

---

在我试图解决涉及大型数据集的特定问题时，我想到了这个问题。

本质上，每当对特定数据集进行更改时，我都会返回完整的数据集，并且我必须在浏览器中呈现这些数据。

因此，例如，在 websocket 上，我收到一个推送事件，告诉我数据集发生了变化，然后我必须通过抓取现有的 DOM 元素，复制它，使用类名用这个集合中的数据填充元素，以 HTML 呈现这个数据集或其他元素标识符，然后将其添加回 DOM。

请记住，此数据集中的任何对象（JSON）可能有多达 1000+ 个子对象，并且可能有多达 10,000+ 个父对象，因此您可以看到可能存在返回数据集向上的实例朝向 1,000,000 => 10,000,000 个数据点或更多。

现在有趣的部分来了，我必须渲染这些东西。对于每个数据点，可能有 3 或 4 个标签用于呈现和设置数据样式，并且可能有任何这些标签的事件侦听器（可能在父容器上使用委托来减轻事情）。

总而言之，可能有很多传入信息需要呈现，我正在尝试找出处理这种情况的最佳方法。

理想情况下，您只想呈现发生更改的单个数据点的更改，而不是重新呈现整个集合，但由于后端的设计方式，这可能不是一个选项。

我在这里主要关心的是了解浏览器/DOM 的局限性，并从前端的角度来看这个问题。后端肯定会发生一些变化（数据设计、缓存、分页），但这不是这里的重点。

这不是 HTML/DOM 的 典型 用例，因为我知道存在限制，但它们到底是什么？我们是否仍然限制在大约 3000-4000 个元素？

---

我有很多 相关 的 子 问题正在 积极 查找 ， 但我认为与 stackoverflow 社区的其他成员分享一些想法并尝试将有关此问题的一些信息汇集在一起会很好。

现代浏览器在开始变得缓慢/无响应之前可以处理的“合理”数量的 DOM 元素是多少？

如何对浏览器可以处理的 DOM 元素数量进行基准测试？

处理需要渲染的大型数据集有哪些 策略（除了分页）？

与使用 jQuery 或正则表达式相比，从 data/json（在前端）渲染 html 的模板框架（如 mustache 和 handlebars）是否更高效？

原文由 qodeninja 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 1

这是一个只有精通统计学的答案才能准确和全面的问题。

为什么

合适的方程是这样的，其中 N 是节点数，字节数N是在 DOM 中表示它们所需的总字节数，节点索引范围是 n ∈ [0, N) ，bytesOverhead 是用于一个节点的内存量具有绝对最小属性配置且没有 innerHTML 的节点，bytesContent 是用于填充此类最小节点的内存量。

字节N = ∑ N (bytesContent n + bytesOverhead n )

问题中要求的值是 N 在最坏情况下的手持设备、操作系统、浏览器和操作条件下的最大值。为每个排列求解 N 并非易事。上面的等式揭示了三个依赖项，每个依赖项都可能极大地改变答案。

依赖关系

1. 节点的平均大小取决于每个节点用于保存内容（例如 UTF-8 文本、属性名称和值或缓存信息）的平均字节数。
2. DOM 对象的平均开销取决于管理每个文档的 DOM 表示的 HTTP 用户代理。 W3C 的 文档对象模型常见问题解答 指出，“虽然所有 DOM 实现都应该是可互操作的，但它们在代码大小、 内存需求 和单个操作的性能方面可能会有很大差异。”
3. 可用于 DOM 表示的内存取决于默认使用的浏览器（这可能因手持设备供应商或用户喜欢的浏览器而异）、默认浏览器的用户覆盖、操作系统版本、手持设备的内存容量设备、常见后台任务和其他内存消耗。

严格的解决方案

可以运行测试以确定 (1) 和 (2) 用于手持设备上使用的每个常见 http 用户代理。可以通过配置 Web 服务器的日志记录机制来获取任何给定站点的用户代理分布，以放置 HTTP_USER_AGENT（如果默认情况下不存在），然后在日志中剥离除该字段以外的所有字段并计算每个值的实例.

每个字符的字节数需要针对属性值和 UTF-8 内部文本（或任何编码）进行测试，以获得一对用于计算 (1) 的明确因素。

可用的内存也需要在各种常见条件下进行测试，这本身就是一项重大的研究项目。

选择的 N 的特定值必须为零才能处理实际的最坏情况，因此可以选择一定比例的内容、节点结构和运行时条件的典型情况。例如，可以使用某种形式的随机 _原位_（在正常环境条件下）研究来获取案例样本，并找到满足 95% 这些案例的 N。

或许可以用上述方法测试一组案例，并将结果放在表格中。这代表了对您问题的直接回答。

我猜想一个受过良好教育的移动软件工程师需要数学，特别是统计，五个全职周才能获得合理的结果。

更实际的估计

人们可以猜测最坏的情况。经过整整几天的研究和一些概念验证应用程序，这个提议可以得到改进。没有时间这样做，这是一个很好的初步猜测。

考虑允许 1 GB 用于 DOM 的手机，因为正常操作条件使用 4 GB 中的 3 GB 用于上述目的。人们可能会假设一个节点的平均内存消耗如下，以获得一个大概的数字。

• 每个节点 40 个字符的内部文本每个字符 2 个字节
• 4 个属性值每个字符 2 个字节，每个 10 个字符
• 4 个属性名称，每个字符 4 个字符，每个字符 1 个字节
• 在效率较低的情况下，C/C++ 节点开销为 160 字节

在这种情况下 N worst_case ，最坏情况下的最大节点数，

 = 1,024 X 1,024 X 1,024
  / (2 X 40  +  2 X 4 X 10  +  1 X 4 X 4  +  160)

= 3,195,660 . 190,476.

但是，如果完全可以避免的话，我不会在具有三百万个 DOM 节点的浏览器中构建文档。考虑采用以下更常见的做法。

常见做法

最好的解决方案是保持远低于 N worst_case可能的值，并使用标准 HTTP 设计技术将节点总数减少到可能的程度。

• 减少任何给定页面上显示的内容的大小和复杂性，这也会提高视觉和概念的清晰度。
• 从服务器请求最少数量的数据，使用窗口技术延迟尚不可见的内容，或以精心计划的方式平衡响应时间和内存消耗。
• 使用异步调用来协助实现上述极简主义。

原文由 Douglas Daseeco 发布，翻译遵循 CC BY-SA 3.0 许可协议

Answer 2

你的答案是：1 或数百万。我将复制/粘贴 SO 上类似问题的答案。

老实说，如果您真的需要这个问题的绝对答案，那么您可能需要重新考虑您的设计。

这里给出的答案都不会是正确的，因为它取决于许多特定于您的应用程序的因素。例如，大量使用 CSS 与少量使用 CSS、div 的大小、每个 div 所需的实际图形渲染量、目标浏览器/平台、DOM 事件侦听器的数量等。

仅仅因为你可以并不意味着你应该！ :-)”

请参阅： 在 dom 变慢并变得不稳定之前，您可以拥有多少个 div？

这确实是一个无法回答的问题，涉及太多角度太多因素。然而，我要说的是，在单个页面加载中，我使用 1ms 的 javascript setinterval 不断向页面添加新的 div，ID 递增 1。我的 Chrome 浏览器刚刚超过 20,000，并且正在使用 600MB Ram。

原文由 tremor 发布，翻译遵循 CC BY-SA 3.0 许可协议