所以这是一个奇怪的问题，我真的在这里寻找一些最佳实践和潜在的解决方案。
背景
我正在研究一个非常重要的企业应用程序。这是一个单页应用程序，除了初始加载，应用程序中没有完整的页面加载。几乎所有服务事务都返回JSON。
该应用程序生成大型数据集，其中一些数据集可以超过1到2 MB未压缩。这显然是不可取的，但鉴于我们的应用程序的复杂性和它的作用，它也不是我们可以很容易地以实质性方式改变的东西。因此，我们在IIS中为JSON和XML启用了动态压缩，在500K未压缩的JSON包中有效地将我们降低到大约47K。
（让IIS动态压缩JSON和XML根本就是一件苦差事，所以如果有人需要提示，我很乐意帮忙。）
问题状态：
我们很高兴能够缩小我们的数据集，但是我们注意到IE11似乎与在AJAX响应对象中返回的压缩数据相比较差。基本上发生的是，当IE解压缩从AJAX请求返回的GZipped数据时，UI层中存在可见的暂停。它并不实质（1.5秒），但相当明显。我们测试的其他浏览器都没有受到此影响; Chrome，Safari，FireFox，Opera ...都会解压缩并处理此压缩数据，而UI中没有任何可见的暂停。所以，这似乎是IE迷人的怪癖之一。
尝试解决方案：
我们尝试通过优化对象大小以及调整压缩级别来减少这种情况。其中，减少起始对象大小是唯一成功减少渲染延迟的因素;压缩级别似乎很少或根本没有。但正如我所说，我们已经达到了我们可以做的优化数据大小的外部限制。
我需要什么：
理想情况下，有人遇到同样的问题，可以提供有关我们如何解决IE11问题的建议。或者，如果有人能够深入了解IE如何处理gZipped响应，以及为什么这种差异可以归结为完全停止在浏览器UI中发生的任何事情，我会很激动。
我远不是一名IIS专家，所以说话要慢，用小词; - ）
答案 0 :(得分：0)
IE没有理由在这里慢一点; GZIP内容在网络堆栈中向下扩展，使用的代码基本上是Zlib的一个端口，几乎与所有其他浏览器使用的相同。
您是否使用IE的F12开发人员工具分析器来查看性能？
如果在Fiddler运行时加载站点并且其工具栏中的“解码”选项设置为“启用”，性能是否会发生变化？