IE 中的 jQuery 数据表优化，96.7% 的时间花在 offsetWidth 上

Question

我有一个使用 datatables.net 1.9.4 和 jQuery 渲染的相当大的表。我异步提取数据，然后在数据表初始化中设置aaData 和aoColumns。

虽然它在 Chrome 中几乎立即显示，但在 IE9 中，需要 6 分钟才能显示。

IE 的 分析器显示 96.7% 的时间花在 offsetWidth 函数上。 offsetWidth 在哪里以及何时调用？我找不到该名称的函数。

这是我的初始化选项:

aaData: data.Values,
aoColumns: data.Headers,
bProcessing: true,
bDeferRender: true,
bDestroy: true,
bFilter: false,
bPaginate: false,
bSort: false,
sScrollY: fnCalcDataTableHeight(690),
sScrollX: "100%",
bScrollCollapse: true,
bInfo: false,

我还有唯一的aoColumnDefs。

谢谢。

Answer 1

offsetWidth 是元素布局宽度的只读值，包括元素的宽度、水平内边距、水平边框和滚动条(如果有)。 JQuery 的 outerwidth() 给出了同样的结果。

每次向 DOM 添加或删除某些元素时，都必须调整渲染树。当您添加新元素时，将会发生回流和重绘，以使用新元素计算文档的新布局，并使用新样式(如果有)在浏览器上重新绘制它。

现代浏览器尝试通过对这些更改进行排队并立即刷新它们来进行一些优化，以尽量减少这些昂贵的操作。但是，当您的脚本要求一些值(例如 offsetWidth)时，无法应用这些优化，因为它是布局的值，因此必须刷新队列中待处理的所有布局更改，然后返回最终值让 offsetWidth 准确。所以我们应该尽量减少它的使用。 Here's关于这个主题的有趣读物。即使在最坏的情况下，Chrome 仍然会尝试进行一些优化，但 IE 不会。

针对您的问题，数据表插件可能在内部使用它。您可以采取其他方法，而不是尝试更改插件。

使用 DocumentFragment，自行生成所有表格行，将它们附加到表格中，然后在其上应用数据表小部件。如果您的行和列太复杂，请尝试使用模板引擎。从 here 中选择

上次遇到这个问题时，我们有一个复杂的表，并将行数限制为 500 并使用了分页。如果你的表很简单，你的阈值可以很大，但考虑到 IE 就不会更大:)