我有一个非常繁重的报告，我在一个html表中呈现。它是动态的，有时它可以有100行乘以100列，有时它可以达到1000行以上。 此报告还有不同的可视化方式，因此我使用CSS来显示/隐藏某些值，具体取决于我希望看到它的方式。行中的数据就像树一样，所以我使用按钮来显示/隐藏子行以模拟树的效果（默认情况下，子行是“关闭”/显示：无）。
问题在于，当我收到1000行的大型报告之一时，浏览器有时（几乎总是在Chrome上，有时在Firefox上）需要很长时间（超过5分钟） decrompress HTML（来自Ajax调用）。整个事情大约有37mb解压缩，有时候浏览器会快速管理它，有时它很慢。
我唯一能想到的就是渲染报告的不同“视图”部分（意思是html的小块），但后来我需要处理整个事情至少三次（按需）所以用户会看到所有可能的组合。
当hmlt为30mb plus时，我才开始遇到这个问题。我知道我必须做的事情有些非常错误，但是我不知道从哪里开始我读到的关于html性能的东西似乎并不适用。我没有在回调上运行的jquery绑定，所以它与此无关。
修改
我在用较小的块渲染之后进行了一些测试（较大的块从35mb变为21mb。较小的一个现在是2,4mb）。但它似乎与html的大小无关，即使较小的有时也会减慢（5秒，3秒，30秒）。我错了。
我目前正在使用.html（）将ajax调用的结果放在div上，我也尝试使用.load（）。
答案 0 :(得分：0)
您可以开始加载100行，然后使用Ajax加载100行，然后越来越多。
实际上，你不能一次看到整个30多MB的报告，因为监视器的大小，那么你可以动态加载 - 破坏数据。让我们只看到1000行数据。答案 1 :(得分：0)
似乎我一直都弄错了。它与hmlt大小无关，也与浏览器如何处理解压缩无关。问题是，html根本没有被压缩。
当我比较Chrome上的网络标签时，我注意到了它。在我们使用Visual Studio和IIS Express的开发环境中，它显示HTML已被压缩，但在我们的外部沙箱环境中（我运行数据更加繁琐的测试）它没有被压缩。
之前我检查过我们的IIS并且启用了动态压缩，但经过一些研究后我了解到动态请求的默认压缩级别为O，所以我将其更改为4.
http://weblogs.asp.net/owscott/iis-7-compression-good-bad-how-much
但它仍然无法正常工作，我认为它与为IIS压缩启用的mimeTypes有关，但它仍然没有解决问题。
最后，我注意到它在家里很好，但在我工作的地方它仍然很慢。这样做的原因似乎是网络的代理。
noCompressionForProxies可选的布尔属性。
指定是否禁用HTTP 1.1响应以进行压缩 通过代理服务器发出的请求。
注意：某些HTTP代理服务器不处理压缩的缓存 对象正确。您可以使用此设置以避免返回 压缩文件到无法解压缩的代理服务器。
默认值为true。
http://www.iis.net/configreference/system.webserver/httpcompression
这意味着，只是更改压缩级别已经解决了问题。