Google建议：
请注意，仅对更大的资源有利。由于压缩和解压缩的开销和延迟，您只能使用超过一定大小阈值的gzip文件。我们建议最小范围为150到1000个字节。将文件压缩到150字节以下实际上可以使它们变大。
我们通过Akamai使用其网络作为代理和CDN来提供内容。他们告诉我的内容：
关于最小大小的问题，Akamai将在将请求的对象发送给最终用户时对其进行压缩：最小大小为860字节。
我的回答：
Akamai的最小大小为860字节的原因是什么？举例来说，为什么Akamai为Facebook提供的文件不是这种情况？ （请参阅下文）Google建议更积极地gzip。在我们的网站上，这似乎是恰当的，到目前为止，点击率最高的是<860字节的AJAX调用。
Akamai的回答：
原因860字节是压缩的最小大小是双重的：（1）压缩对象的开销860字节以下的数据超过了性能提升。 （2）860字节以下的对象始终可以通过单个数据包进行传输，因此没有迫切的理由对其进行压缩。
所以我在这里进行一些事实检查。由于数据包大小而导致的860字节限制是否在此推理的结尾？为什么高流量站点将其降低到150字节限制...只是为了节省带宽成本（因为CDN的收费基于从原始站点卸载的带宽），或者这样做会提高性能？
12/7/9更新：
我问史蒂夫·苏德斯（Steve Souders），gzip响应中的性能提升是否已经小于数据包，什么是
？为实现gzip性能而建议的最小对象大小
，这是他的回答：
感谢您的来信。大小介于1-5K之间。 Apache具有
默认设置，但我忘记了它的默认设置-这将是一个很好的指南。
我们在F5设备上进行压缩，因此我们将其降低到〜350字节，因为在那和1K之间有相当数量的AJAX调用。我们网站上少于350个字节的AJAX调用全部减少了约70个字节...比Google的建议还少...所以它似乎可以归结为：了解您的网站并根据您的代码进行调整。
在F5更新在生产环境中运行一段时间后，我将返回本文。我认为不会有什么性能上的好处，但由于它们的服务量较少，因此我们会降低Akamai的成本。
#1 楼
您在谈论带宽成本的好处，然后还要比较浏览器中页面加载的性能。它们是两件事。这可能会增加请求的延迟，具体取决于两端硬件的功能。“ gzip的最小大小”是基于压缩/解压缩少量数据而不是压缩数据所需的时间。从网络浏览器体验角度来看很有帮助。如果您纯粹是在谈论带宽节省，那么就继续将最小值设置为所需的最小值，但是要知道可能不会给最终用户带来任何性能提升。
评论
@Steve，关于四月份的编辑，我添加了welp来澄清感觉，因为该领域答复中的专家没有回答任何一个问题。我很高兴听到桑德斯先生的回信，但他也不知道确切的答案。至于“在F5更新在生产环境中运行一段时间后返回本文”，尽管我不再使用该特定的Web应用程序，但我们成功实现了平均页面load（）事件和交互式（TTI）低于2秒，有效负载工作量的减少只是其中的一小部分。减少http流量调用的次数，扩展浏览器缓存，优化代码以及其他Web性能最佳实践，都有助于实现这一目标。