不执行http压缩的下限是多少？
执行http压缩时是否存在建议不执行压缩的低阈值？
显然，对于 100 字节，您不会压缩，而对于 1MB，您会压缩。但是对于具体的低阈值有什么一般性建议吗？
When performing http compression is there low threshold where it is recommended to not perform compression?
Obviously for 100 bytes you would not compress and for 1MB you would. But are there any general recommendation on a specific low threshold?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
IBM 有一个比较，其中还包括一个图表。据它介绍，压缩小文件还有一个好处。 另一个，尽管旧文章描述 gzip 的性能很好，但本地文件传输除外。尽管这两篇文章都在检查“拨号”环境中的压缩，但
我认为问题与要压缩的内容更相关，而不是压缩多少字节。 Gzip (deflate) 通常适用于文本文件（html、xml、js 等），即使它们小至 256 字节，但在压缩媒体文件或已压缩的文件（如 png）时几乎没有用处。 、jar-s、docx/odt-s 等）
IBM has a comparison, which also includes a graph. According to it there is also a benefit for compressing small files. Another, although old article describes gzip's performance as good, except for local file transfers. Although both articles are checking compressions in "dial-up" environment,
I think the question is more relevant as to what to compress, instead of how many bytes. Gzip (deflate) is usually good for textual files (html, xml, js, etc.) even if they are as small as 256 bytes, but is next to useless when compressing media files, or files that have already been compressed (like png, jar-s, docx/odt-s, etc.)
如果您确实关心它，您应该比较应用程序中 gzip 压缩和未压缩的真实文件之间的大小差异。开始测试您提供的最小文件，并测试增加的大小。查看 gzip 压缩后的大小小于未压缩的大小的位置，并将其设置为阈值。
不过，除非您是 Google，1，否则这并没有多大区别。选择一个合理的值。 256 KB 听起来怎么样？
1好吧，好吧...
O(Google)If you really care about it, you should compare the size differences between gzipped and uncompressed real files in your application. Start testing the smallest files you serve, and test increasing sizes. See where the gzipped size is smaller than the uncompressed, and set that to the threshold.
Unless you are Google,1 however, it simply doesn't make much of a difference. Pick a sane value. How does 256 kilobytes sound?
1Okay, okay...
O(Google)压缩短 HTTP 响应并没有多大坏处。如果有的话，它们也不会变得更大。我认为如果 CPU 确实能节省带宽，那么它的努力总是值得的。
更好的担忧是数据的类型。尝试压缩紧凑的二进制文件类型（例如现代图像和视频格式）完全是浪费精力，而对于所有文本内容来说，这都是有效的。
There's not much harm in compressing short HTTP responses. They're not going to get much bigger, if at all. I'd reckon the CPU effort is always worth it if it does save bandwidth.
The better worry is the type of data. Trying to compress tight binary file types like modern image and video formats is a total waste of effort, whereas for all text content it's effective.