我知道在通过网络发送文件之前对文件进行压缩可以节省带宽，对于可以缓存的静态文件，它对服务器端CPU使用率没有太大影响。
但客户呢？他们必须对任何发送的文件进行gunzip，这将占用CPU时间。另外，我担心在进行任何解析之前必须接收整个文件并进行喷枪压缩。
这让我很奇怪，因为我看到两种情况：
1) client has fast internet --> gzip is relevant
2) client has slow internet --> gzip prevents partial parsing
显然，准确的加速（或减速？）将取决于正在传输的文件和客户端的确切情况。但是，我很好奇客户端的时间成本（或者我如何衡量成本）？
答案 0 :(得分：38)
他们必须对任何发送的文件进行gunzip，这将占用CPU时间。
或许，但与加载页面时所发生的所有其他事情相比，用于解压缩的CPU时间非常小（解析，样式，渲染，脚本）。
我担心在进行任何解析之前必须接收整个文件并进行喷枪压缩。
别担心，gzip是数据的“流”，完整的文件不需要开始解压缩/解析。
具体来说，我想知道如何判断因为gzipping而损失了多少时间。
Here is an interesting article作者执行您所描述的测试类型。这些工具可供下载，以便您可以在自己的环境中执行相同的测试。
作者总结道：
我想极少数情况下你不应该使用gzip你的内容。如果您的典型页面少于100个字节，则gzipping会损害客户端和服务器的性能。但是没有网站 - 除了一些网络服务 - 提供典型大小为100字节或更少的页面。因此，没有理由提供未压缩的HTML。
答案 1 :(得分：19)
同时（问题已经有点老了）大多数人都在为每个连接使用TLS，所以关于性能的问题变得有点多余。但是仍然值得看一下：
1）客户端具有快速互联网 - ＆gt; gzip是相关的 2）客户端网速较慢 - ＆gt; gzip阻止部分解析
情况恰恰相反。客户端的互联网连接（或到服务器的路由）越慢，您获得gzip压缩（或一般压缩）的优势就越大。
如果压缩/解压缩所需的时间加上传输压缩数据所需的时间少于立即传输未压缩数据所需的时间，压缩会很有用。
Gzip通常会将数据减少到原始大小的1/3到1/2之间（取决于它的大小），压缩大约为50MB / s（+/- 5）。减压速度大约是其3倍。
100MBit以太网的吞吐量约为12.5MB / s，大多数人还没有100MBit的互联网接入（因为它通常堆叠在ATM之上，也比普通的以太网慢）。此外，大多数人大多数时间都无法通过单次下载完全满足其高带宽互联网连接。
所以，实际上，对于普通普通用户和服务器而言，在家中不在您的局域网中，而是“在其他地方”，假设您获得5MB / s（这大约是我拥有的理论最大值的两倍）在这里，顺便说一句。
要传输50kB文件，您需要0.01秒。 gzip压缩增加约0.001秒压缩，0.0003秒解压缩（让我们向上舍入并说总计0.002），但你只需要传输16kB，这需要0.0032秒。
将它们加在一起，使用gzip压缩传输速度大约是其两倍。
当然，最终（当普通用户将拥有200Mbit / s互联网，服务器具有100Gbit / s上行链路时），这个数字将会转变。