浏览器可以正常显示的 html 元素数量是否有限制？
基本上我有一个巨大的表格，当用户向下滚动时它会变得更大（自动预加载后续行）。在某些时候，浏览器变得缓慢，当我单击或尝试滚动时，它开始挂起一会儿，并且它变得更缓慢，它获得的行数越多。我想知道页面可以容纳的元素数量是否有限制？或者也许只是我的 javascript 在某处泄漏（尽管我只有一个事件处理程序，附加到表的 tbody - 以及一个解析冒泡 mousedown 事件的脚本）。
更新：在加载一千行后，延迟变得明显。滚动本身的速度是相当可以忍受的，但是例如突出显示单击的行（在 tbody 上的单个事件处理程序的帮助下）是痛苦的（它至少需要 2-3 秒，并且延迟随着行数而增加）。我观察到所有浏览器上都有延迟。不仅是我，几乎所有访问该页面的人都受到影响，所以我想它在某种程度上影响了每个平台。
更新：我在这里想出了一个简单的例子：http: //client.infinity-8.me/table.php?num=1000 （您可以将任何您想要的数字传递给num），基本上它会渲染一个带有num的表格 行，并且有一个附加到父表的事件处理程序。我应该由此得出结论，实际上，由于子元素的数量而导致性能没有明显下降。所以可能是其他地方泄漏:(
Basically I've got a huge table, which gets even bigger as user scrolls down (auto preloading subsequent rows). At some point browser becomes sluggish, it starts to hang for a moment as I click around or try to scroll and more sluggish it becomes, the more rows it gets. I wonder if there is any limit on number of elements that page can hold? Or maybe it's just my javascript leaking somewhere (although I've got only one event handler, attached to the tbody of the table - and a script that parses bubbled mousedown events).
Update: Delay becomes noticeable after a thousand of loaded rows. The speed of scroll itself is pretty bearable, but for example highlighting of the clicked row (with the help of single event handler on tbody) is painful (it takes at least 2-3 seconds and delay grows with the number of rows). I observe delay on all browsers. It's not only me, but almost everyone who visits the page, so I guess at some extent it affects every platform.
Update: I came up with simple example here: http://client.infinity-8.me/table.php?num=1000 (you can pass whatever number you want to num), basically it renders a table with num rows and has a single event handler attached to a parent table. I should conclude from this, that there actually is no noticeable dropdown in performance, caused by number of child elements. So it's probably a leak somewhere else :(
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
您应该注意的另一件事是桌子的大小。如果您的表格使用
table-width:auto;进行样式化，则浏览器必须测量表格中的每个元素来调整其大小。这可能会变得非常慢。相反，选择固定宽度或至少使用
table-width:fixed设置表格样式。Another thing you should look at is table sizing. If you have your table styled with
table-width:auto;the browser has to measure every single element in the table to size it. This can get insanely slow.Instead, choose a fixed width or at least style the table using
table-width:fixed.我不认为标准定义了限制。每个浏览器实现中可能存在硬编码的限制，尽管我认为该限制可能是数十亿个元素。另一个限制是可寻址内存量。
解决您的问题：除了在向下滚动时自动加载元素之外，您还可以自动卸载已从屏幕上滚动的元素。这样，即使滚动很多次，您的程序仍将保持快速。
您可能还需要考虑替代接口，例如分页。
I don't think there is a limit defined by the standard. There might be a limit hard-coded in each browser implementation, though I would imagine that this limit is likely to be billions of elements. Another limit is the amount of addressable memory.
To solve your problem: As well as automatically loading elements as you scroll down, you could automatically unload the ones that have scrolled up off the screen. Then your program will remain fast even after scrolling a lot.
You may also want to consider an alternative interface such as paging.
如果你在每个表行上都有 JS，那么旧计算机将无法处理它。对于 HTML 本身，您不必太担心。
您应该担心普通人不喜欢大表格，这就是分页的目的。使用分页将其分开，以获得更好的可用性或其他问题。
想想一本没有页数但只有一大页的书，你想读它吗？即使你的眼睛（在我们的例子中是电脑）可以处理它。
If you have got JS on each table row then old computers will not handle that. For HTML itself you shouldn't worry much.
You should worry about fact that normal human being doesn't like large tables this is what pagination is made for. Separate it using paging for better usability nor other concerns.
Think of book that doesn't have pages but one large page, would you like to read it? Even if your eyes (PC in our case) can handle it.
我认为没有限制。
但是，HTML 文件越长，您的计算机需要的资源就越多。但桌子必须很大……
I don't think there is a limit.
However, the longer a HTML file is, the more resources, your computer will need. But the table has to be very large then...
该限制实际上由所使用的用户代理和客户端计算机决定。 HTML 与 XML 一样，都是一种树形数据格式。因此，元素越多，客户端浏览器必须在树中搜索越远才能呈现页面。
我在向 div 添加超过 100 个表时遇到问题（作为 IE6 的旧解决方法，无法动态创建表元素）。
The limit is really determined by the user agent and client machine being used. HTML, in the same way as XML, is a tree format of data. Therefore the more elements, the further through the tree the client browser has to search to render the page.
I had issues adding more than 100 tables to a div (as an old workaround to IE6 not being able to create table elements dynamically).
您使用什么浏览器？有些浏览器可以比其他浏览器更好地处理事情 - 例如，如果您使用 IE，如果它运行缓慢我不会感到惊讶 - 它不能像基于 webkit 的浏览器一样处理 javascript 事件。
另一件事显然是你的计算机（RAM 和 CPU）。但说实话，大多数计算机不应该有这个问题，除非我们谈论 10000+ 行......甚至那样......
你能发布一些代码吗？
What browser are you using? Some browsers can handle things better than others - for instance, if you're using IE, I wouldn't be surprised if it's sluggish - it doesn't handle javascript events as well as webkit based browsers.
The other thing is obviously your computer (RAM and CPU). But to be honest, most computers shouldn't have a problem with that unless we're talking 10000+ rows... and even then...
Can you post some code?
鉴于存在多种浏览器和渲染引擎，并且它们都具有不同的性能特征，并且考虑到这些引擎在性能方面稳步提高，并且计算机硬件始终变得更快：不，浏览器的性能没有固定的上限处理。但是，当前特定版本的浏览器的特定硬件存在上限。
如果您不进一步定义您的硬件和浏览器，则很难为您提供帮助。另外，如果您不发布代码，没有人可以对您的 Javascript 的可能性能提出任何建议。即使它只是一个事件处理程序，如果它无限循环或者为每个元素调用，它也会大大减慢渲染过程。
Given that there exists a multitude of browsers and rendering engines and all have different performance characteristics and also given that those engines get steadily improved in regard to performance and computer hardware gets faster all the time: No there is no fixed upper limit what a browser can handle. However, there are current upper limits on specific hardware for specific versions of browsers.
If you do not define more what your hardware and browser are its hard to help you. Also, noone can make any suggestion in regard to the possible performance of your Javascript if you don't post the code. Even if it's just one event handler, if it loops infinitly or if its called for each element, it can considerably slow down the rendering process.
不管 RAM 或 CPU 使用情况，预加载后文件的实际大小是多少？
如果您的表真的那么大，您可能会强迫您的用户下载兆字节的数据 - 我发现有些机器在下载 2-4MB 的数据后往往会挂起。
Nevermind RAM or CPU usage, what's the actual size of the file after it preloads?
If your table is really that huge, you could be forcing your users to download megabytes of data - I've found that some machines tend to hang after 2-4MB of data.
视情况而定。例如，IE 在加载所有内容之前不会开始渲染表格。因此，如果您有一个 5,000 行的表，它需要在渲染任何数据之前加载所有 5,000 行数据，而其他浏览器一旦拥有部分数据就开始渲染，并随着表的增长进行一点调整（如果需要）。
一般来说，渲染速度会随着节点数量的增加而变慢，而且会随着节点的复杂性而变慢...避免嵌套表，如果可能的话，尝试将巨大的表分成块...例如每 100 行（如果可能）
Depends. IE for example will not start rendering a table until all the content is loaded. So if you had a 5,000 row table it needs to load all 5,000 rows of data before rendering any of it where as other browsers start rendering once they have partial data and just adjust a bit (if needed) as the table grows.
Generally speaking rendering slows with the quantity of nodes but also with the complexity of nodes... Avoid nested tables, and if at all possible, try to break up huge tables into chunks... E.g. Every 100 rows (if possible)
世界上确实没有理由在单个页面上发布整个庞大的数据集。如果要求向用户提供所有这些数据，那么您应该将其导出到一个可以由比浏览器更好的软件读取的文件。
相反，我建议您创建一个 AJAX 驱动的页面，让用户看到部分数据，如果他们需要查看更多数据，您只需下载数据集的该部分并替换页面上的当前数据集。这是分页。谷歌搜索就是一个很好的例子。
There really isn't a reason in the world for publishing an entire huge dataset on a single page. If the requirement is to provide the user with all that data, then you should export it to a file that can be read by some better software than a browser.
Instead, I suggest that you make an AJAX driven page, where you let the user see a portion of the data and if they need to see more, you would just download that portion of the dataset and replace the current dataset on the page. This is pagination. Google search is an excellent example of this.
如果有任何限制，则取决于浏览器。但您遇到的问题与限制无关，因为浏览器仍然显示该页面。
大表始终是浏览器的问题。渲染一个大表需要花费大量时间。
因此，将大表拆分为较小的表通常是个好主意。
此外，您可能想要指定列宽。如果没有它，浏览器必须下载整个表格，然后才能计算每列的宽度并呈现表格。如果您在 HTML 代码中指定宽度，则浏览器可以在下载页面时显示该页面。 （注意：指定整个表格的宽度是不够的，您需要指定每列的宽度。）
如果使用 Javascript 将一行添加到一个大表格中，浏览器很可能必须渲染整个表格再次表。这就是它变得如此缓慢的原因。如果您有较小的表，则只需再次渲染一张小表。更好的是，如果一次加载一个子表而不是只加载一行。
但最有效的方法是将数据拆分为多个页面。用户可能也更喜欢这样。这就是为什么谷歌在每个页面上只显示这么多结果的原因。
If there are any limits, it depends on the browser. But the problem you have it not about limit, since the browser still displays the page.
Big tables are always problem with browsers. Rendering a large table takes lots of time.
Therefore, it is often good idea to split a large table into smaller tables.
Further, you probably want to specify the column widths. Without that, the browser has to download the whole table before it can calculate width of each column and render the table. If you specify the widths in the HTML code, the browser can display the page while it is still downloading. (Note: specifying the width of the whole table is not enough, you need to specify the width of each column.)
If you add a single line into a big table using Javascript, the browser most likely has to render the whole table again. This is why it becomes so slow. If you have smaller tables, only the one small table needs to be rendered again. Better still, if you load one sub-table at a time instead of just one line.
But the most effective method is to split the data into multiple pages. The users probably prefer that, too. That is why for example Google displays only so many results on each page.