大型html表速度慢吗？

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

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

---

表是我的问题的根源吗？

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

---

抱歉说得这么含糊，但通常情况下，表的渲染速度并不慢，但由于缺乏可访问性而被人看不起（当然，很多理想主义是屏幕阅读器不喜欢它们）。

据我所知，如果没有明确说明宽度，HTML表的渲染速度可能会很慢。如果没有，浏览器必须在计算正确的宽度之前完成单元格内容的加载。

MSDN有一些关于他们的“”文章的信息可能会有所帮助；他们建议如下（具体针对表格）：

• 在表格上将表格布局CSS属性设置为

  fixed

• 为每列显式定义

  col

  对象
• 在每个

  列上设置宽度属性

---

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

如果您知道每列的宽度，请尝试在CSS中为表指定

表布局：fixed

，看看这是否有任何区别（它应该会阻止浏览器仅仅因为切换了几行的可见性而尝试重新渲染整个表。）

无论你想出什么主意，在几个平台上的几个浏览器中测试这种方法，使用一些速度较慢的机器。我曾经有一个应用程序，除了在Safari for Macintosh中，它在任何地方都很快。结果是它呈现下拉列表的方式。实验是无法替代的。嗯，我的意思是测试。IE根本无法处理非常大的DOMs操作

---

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

根据经验，我可以说几乎肯定是下拉列表导致了速度缓慢。具有数百行的表c如果只包含文本，渲染几乎是瞬间完成的，但在每一行中添加一个下拉列表，只需几十个选项，现在即使是50行也需要相当长的时间

---

试着围绕表格行中下拉列表的需要进行设计-如果这是一个表单（为什么会有下拉列表？），让用户选择他们想要编辑的行，然后将可编辑控件仅放在该行中，如果你喜欢这种类型的东西，可以通过AJAX，也可以使用更传统的“细节视图”方法。

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

---

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

每个下拉列表中有多少项？列表是否在每行重复？使用哪个浏览器（HTML查看器）重要吗您正在使用？根据@Ernestrings的评论在我的答案中添加了asp.net标记。@Ernestrings--我今天不在，所以明天我会给您一个示例。同时，我认为“重新设置控件”是个问题。也许数百行应该重新考虑？另一种选择是基于AJAX的“根据需要加载”行？只是想一想，少一些滚动ing=快乐用户。非常感谢您提供的信息来源。是否有任何实际的基准，我们可以清楚地看到差异？