大型 html 表慢吗？答案

【问题标题】：Are large html tables slow?大型 html 表慢吗？
【发布时间】：2010-11-24 18:04:54
【问题描述】：

我最近一直在开发一个使用包含大量（数百）行的表的应用程序。这些行包含表格数据，每行包含两个下拉列表以及在其下方显示隐藏表行的链接。

我目前在尝试从下拉列表中选择一个值以及显示隐藏的表格行时遇到了长时间的延迟。

表格是我的问题的根源吗？

【问题讨论】：

每个下拉列表中有多少项？列表是否在每一行重复？
您使用的浏览器（HTML 查看器）是否重要？
根据@ErnieStrings 对我的回答的评论添加了 asp.net 标签。 @ErnieStrings——我今天出去了，所以明天我会给你一个样品。同时，看看

【解决方案1】：

据我所知，如果没有明确说明宽度，HTML 表格的呈现速度可能会很慢。如果不是，浏览器必须先完成单元格内容的加载，然后才能计算出正确的宽度。

MSDN 在他们的“Building High Performance HTML Pages”文章中有一些信息here 可能会有所帮助；他们提出以下建议（特别是关于表格）：

在桌子上将 table-layout CSS 属性设置为fixed。

为每一列显式定义col 对象。

在每个col 上设置WIDTH 属性。

【讨论】：

非常感谢来源。是否有任何实际的基准可以让我们清楚地看到差异？

【解决方案2】：

问题很可能是控件的呈现（100 个选择框）而不是表格布局。下拉列表中有多少项？它在不同操作系统上的所有浏览器中的执行方式是否相同？

抱歉说得含糊不清，但通常表格的渲染速度并不慢，但由于缺乏可访问性而被看不起（当然，大部分理想主义是屏幕阅读器不喜欢它们的事实）。

【讨论】：

我认为“重新控制控件”是问题所在。也许应该重新考虑数百行？另一种选择是基于 AJAX 的“按需加载”行？只是一个想法，更少的滚动 = 快乐的用户。

【解决方案3】：

我可以根据经验表明，几乎可以肯定是下拉列表导致了缓慢。如果包含数百行的表格仅包含文本，则它们几乎可以立即呈现，但只需为每行添加一个下拉列表，只需几十个选项，现在即使 50 行也将花费大量时间。

尝试围绕表格行中下拉菜单的需求进行设计 - 如果这是一个表单（以及为什么会有下拉菜单？），让用户选择他们想要编辑的行，然后只放置可编辑控件在那一行中，如果您喜欢这种事情，可以通过 AJAX，或者更传统的“详细视图”方法。

【讨论】：

【解决方案4】：

在显示包含数千个条目的静态表格时，我没有注意到任何速度下降，但添加排序或动态斑马条纹等效果可能会很快导致速度较快的计算机上的现代浏览器陷入瘫痪。确保您没有在整个表中运行任何 JavaScript 迭代。

【讨论】：

【解决方案5】：

无论你想出什么，在几个平台上的几个浏览器中测试这个方法，用一些速度较慢的机器。我曾经有一个应用程序，除了 Macintosh 的 Safari 之外，它在任何地方都很快。事实证明，它与渲染下拉菜单的方式有关。实验是无可替代的。嗯，我的意思是测试。

【讨论】：

【解决方案6】：

如果您知道每列的宽度，请尝试在 CSS 中为表格指定 table-layout: fixed，看看是否有任何不同（它应该会阻止浏览器尝试重新渲染整个表格，因为您已经切换了几行的可见性。）

【讨论】：

【解决方案7】：

IE 根本不能很好地处理非常大的 DOM 操作。

如果您在每一行中有两个选择和一个链接，假设每个选择有 5 个选项，即 (((5options + 1select) * 2) + 1 link + 3tds + 1tr) 每个选项至少 17 个 DOM 项排。另外，如果我没记错的话，ie 将每个文本项视为它自己的 DOM 节点。因此，为下拉文本添加另外 10 个 DOM 节点，为链接添加 1 个节点，即每行 28 个 DOM 项。

【讨论】：

【解决方案8】：

我同意其他人的观点，即导致加载缓慢的不仅是您的表格，还有下拉列表的填充量。

如果有帮助，您可以尝试对表格进行分页。您可以使用 JavaScript 框架，例如 jQuery 或 extjs 进行分页和 AJAX。

【讨论】：