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