在性能下降之前，浏览器可以安全地处理多少个元素 ID？答案

【问题标题】：How many element id's can browsers safely handle before performance degredation?在性能下降之前，浏览器可以安全地处理多少个元素 ID？
【发布时间】：2011-08-05 03:17:57
【问题描述】：

使用元素 ID 是 javascript 获取元素的最快方式。是否有经验法则或最佳实践指南来说明应该使用多少个这些 id 才能预期浏览器性能开始下降？

【问题讨论】：

你的意思是你可以调用多少次document.getElementById 才能开始减速？
相关：how many div's can you have before the dom slows and becomes unstable?
我会选择无限。试着证明我错了:)
我不担心电话的数量，我不明白为什么会有所作为。我担心每个单独调用的运行时间。假设您有 1000 多个带有 ID 的 DOM 元素，这会导致 getElementById 调用性能下降吗？

标签： javascript performance browser

【解决方案1】：

ID 本身只是一个属性值。唯一的“性能”问题是浏览器必须下载的额外位和字节。从 JavaScript POV 来看，DOM 中的元素越多，遍历它所需的时间就越长，但这与您可能使用的 ID 数量没有直接关系。

编辑：

澄清一下你的JS是不是这样的：

document.getElementById("myID")

您的 HTML 是否如下所示并不重要：

<div id="div1">
  <div id="div2">
    ...
      <div id="div999">
        <div id="myDiv">

或者这个：

<div>
  <div>
    ...
      <div>
        <div id="myDiv">

对于这两个示例，JS 应该运行相同。

【讨论】：

因此 JavaScript 调用的性能仅受 DOM 数量的影响，而不是具有 ID 的 DOM 数量。浏览器不会创建哈希或其他东西来通过 ID 查找 DOM 元素吗？性能会随着“哈希”大小的增加而降低吗？
只有一个 DOM。 DOM 有节点，每个节点都是一个 HTML 元素。节点越多，javascript 爬过它所需的时间就越长。 ID 只是一个属性，所以使用的数字与 JS 性能没有直接关系。

【解决方案2】：

我们有一个包含 1,000 多个字段的表单（不要问），使用 jQuery Validate 进行客户端验证。这包括验证需要哪些字段、检查每个字段的数据类型、根据特定条件显示/隐藏字段组以及在输入数据时跨多个字段运行计算。

只有 MSIE 在这种规模下会放慢速度。 Firefox 和 Chrome “立即”运行验证。 MSIE 最终显示“长时间运行的脚本”对话框。昨晚我收到通知，现在需要额外的字段。

【讨论】：

这些字段的引用是缓存的（在变量/数组/对象中）还是在验证过程中使用$('#id') 来查找每个字段？
@Šime Vidas - 表单的元素集合已经拥有其控件的实时集合。特定元素所需的验证类型通常由类值指示，例如
@RobG 啊哈，那么 IE 的慢可以归因于它的 JavaScript 引擎慢。改善 IE 情况的唯一解决方案是优化/重构代码。

【解决方案3】：

复杂的页面意味着要下载更多字节，这也意味着 JavaScript 中的 DOM 访问速度较慢。例如，当您想要添加事件处理程序时，如果您在页面上循环遍历 500 或 5000 个 DOM 元素，则会有所不同。

大量的 DOM 元素可能是一种症状，即应该通过页面标记来改进某些内容，而不必删除内容。您是否出于布局目的使用嵌套表？您是否只是为了解决布局问题而投入更多 s？也许有更好、语义更正确的方式来做你的标记。

YUI CSS 实用程序对布局有很大帮助：grids.css 可以帮助您进行整体布局，fonts.css 和 reset.css 可以帮助您去除浏览器的默认格式。这是一个重新开始思考标记的机会，例如，仅在语义上有意义时才使用 s，而不是因为它呈现新行。

DOM 元素的数量很容易测试，只需在 Firebug 的控制台中输入： document.getElementsByTagName('*').length

【讨论】：

就 DOM 元素而言，您希望保持在上限是否有任何公认的最佳实践？我在一台非常快的机器上，所以虽然我的机器上的一切都运行得非常顺利，但我担心用户在较弱设备上的体验，包括 iPad 等移动设备。对于这些移动浏览器可以处理的负载是否有任何共识？
iPad 绝不是一个“弱”设备。唯一常用的经验法则是“将您的页面 + 资产保持在 100k 以下”，但这只是经验法则，更多地与传统带宽问题有关。如今，许多 Web 应用程序在 DOM 结构方面都非常复杂。除了构建、测试和重新测试之外，没有一成不变的规则。重复。