"现代"浏览器可以同时"处理"多少个HTML元素？

Question

"现代",因为该定义可能会随着时间而改变(具体而言,我指的是桌面浏览器)

"处理"因为根据机器配置/内存可能会有所不同,但具体而言我指的是一般用例.

---

对于我正试图解决的涉及大型数据集的特定问题,我想到了这个问题.

基本上,每当对特定数据集进行更改时,我都会返回完整的数据集,并且必须在浏览器中呈现此数据.

例如,在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或正则表达式相比,使用数据/ json(在前端)渲染html等模板框架(如胡子和把手)的性能更高吗？

Answer 1

你的答案是:1或数百万.我打算在SO上复制/粘贴类似问题的答案.

说实话,如果你真的需要这个问题的绝对答案,那么你可能想重新考虑你的设计.

这里没有给出答案是正确的,因为它取决于许多特定于您的应用的因素.例如重度与小CSS的使用,div的大小,每个div所需的实际图形渲染量,目标浏览器/平台,DOM事件监听器的数量等.

只是因为你不能意味着你应该!:-)"

请参阅:在dom减速并变得不稳定之前,你能拥有多少div？

这确实是一个无法回答的问题,在太多角度有太多因素.我会说这个,然而,在单页加载中,我使用了1ms的javascript setinterval来不断地将新的div添加到ID递增1的页面.我的Chrome浏览器刚刚超过20,000,并且使用600MB Ram.

Answer 2

对于那些想知道的人：Google 有其Dom 尺寸建议：

Domsize 建议

”

最优 DOM 树：

• 节点总数不到 1500 个。
• 最大深度为 32 个节点。
• 没有父节点具有超过 60 个子节点。

一般来说，寻找仅在需要时创建 DOM 节点并在不再需要时销毁它们的方法。

如果您的服务器附带一个大型 DOM 树，请尝试加载您的页面并手动记录显示哪些节点。也许您可以从加载的文档中删除未显示的节点，并仅在用户手势（例如滚动或单击按钮）后创建它们。

如果您在运行时创建 DOM 节点，子树修改 DOM 更改断点可以帮助您查明节点的创建时间。

如果无法避免大型 DOM 树，提高渲染性能的另一种方法是简化 CSS 选择器。请参阅减少样式计算的范围和复杂性。

”

Answer 3

对于这个问题，只有统计上精明的答案才能是准确而全面的。

为什么

合适的等式是，其中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表示的内存取决于默认情况下使用的浏览器（具体取决于浏览器手持设备供应商或用户喜欢的浏览器），用户对默认浏览器的覆盖，操作系统版本，手持设备的内存容量设备，常见的后台任务以及其他内存消耗。

严谨的解决方案

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

需要针对每个属性值和UTF-8内部文本（或其他编码）测试每个字符的字节数，以获得一对清晰的计算因子（1）。

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

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

也许可以通过上述方式测试一组案例，并将结果放在表格中。这将直接回答您的问题。

我想这需要一个受过良好教育的移动软件工程师，要学习数学，尤其是统计学，要花5个全日制工作周才能得出合理的结果。

更实际的估计

人们可能会猜到最坏的情况。经过几天的研究和一些概念验证的应用程序，可以完善此建议。缺少这样做的时间，这是一个很好的第一个猜测。

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

• 每个字符2个字节，每个节点40个字符的内部文本
• 每个字符2个字节，每个10个字符的4个属性值
• 每个字符1个字节，每个4个字符的4个属性名称
• 在效率较低的情况下，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.

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

普通做法

最好的解决方案是保持远低于N _最坏情况，并使用标准HTTP设计技术将节点总数尽可能地减少。

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