问：

背景

我在 ASP.NET Web 应用程序中有一个数据表。此表包含在 .当我运行生成大量数据（5,000 行和 ~20 列）的查询时，此表需要很长时间才能更新，但仅在 Chromium 浏览器中。“很长”是指~30秒。在 Firefox 中，表格可能需要 ~5 秒才能更新，其中大部分时间用于等待服务器检索、处理数据并将其发送到客户端。此外，Chrome 选项卡使用 ~1.1GB 内存，Firefox 选项卡使用 ~650MB。UpdatePanel

还有一个附加查询，可将视图扩展到 ~45 列。运行此过程时，Chromium 浏览器需要 ~2 分钟来处理此问题，并且大多数情况下会因内存不足问题而失败，在浏览器终止该进程之前，选项卡的容量达到 ~3.9GB。在这种情况下，Firefox 再次需要 ~7 秒的更新时间，并且使用的内存要少得多 （~800MB）。

使用 Chrome 的工具进行调试时，我将问题缩小到一个长时间运行的调用。电话是：MicrosoftAjaxWebForm.js

updatePanelElement.innerHTML = rendering;

updatePanelElement是我的 ASP ，并且是一个字符串，表示整个新表数据的 HTML。示例查询的此字符串的长度为 21752850 （~21MB）。UpdatePanelrendering

我尝试过什么

经过一些初步搜索，我开始怀疑 Chrome 中可能没有使用硬件加速来完成此任务，正如本答案中提到的，Chrome 似乎并不总是使用它，所以我尝试将我的表添加到 CSS 中。这没有效果。transform: translate3d(0, 0, 0);

在此之后，我尝试单独解析新表数据的 DOM，最初按照此处答案中的建议使用，然后按照此处答案中的建议使用。在这两种情况下，在两个浏览器中实际解析 DOM 的调用都很快（轻松不到半秒），但是当尝试使用 where is created by 来附加新解析的节点时，更新仍然和以前一样慢在 Chromium 浏览器中。Firefox仍然和以前一样快。DOMParsercreateContextualFragmentupdatePanelElement.appendChild(frag);fragDocumentFragmentcreateContextualFragment

还有其他人遇到过这个问题吗？有没有人对为什么 Chrome 的这个大更新比 Firefox 慢得多有什么建议？我知道有一个包含 ~21MB 数据的表并不理想，但目前无法对其进行分页，显然可以快速呈现，因为 Firefox 管理得很好。最后，有没有人能够提出解决方案，或者我可以尝试的任何其他技术？