在网络传输中，Gzip压缩是一种普遍使用的性能优化手段，它通过减少数据体积来降低带宽消耗并提升加载速度。Gzip到底能压缩多少体积？能带来多大的速度提升？
体积缩小：平均60%~80%
Gzip对文本类资源（HTML、CSS、JavaScript、JSON、XML等）效果显著,实际测试中：
- HTML：压缩后可缩小70%~80%，一个未压缩的30KB页面，压缩后仅6~9KB。
- CSS/JS：压缩比通常在50%~70%之间，尤其是带有大量重复字符的代码,效果更佳。
- JSON/API响应：压缩比可达80%~90%,例如一个100KB的API响应可压缩至15KB左右。
- 图片/视频/二进制文件：Gzip对这类资源几乎无效，因为它们已被内部压缩过（如JPEG、PNG、MP4）,强行压缩会增加CPU开销且体积变化极小。
文本文件平均压缩率为60%~80%，部分数据甚至可达90%，体积越小,传输越快。
速度提升：加载时间缩短30%~70%
速度提升取决于压缩体积与压缩/解压时间的平衡,以下是实际场景中的数据：
- 网页首屏加载：一台服务器未开启Gzip时，传输30KB的HTML需要约400ms（假设1Mbps网络）；开启后体积降至8KB，传输时间缩短至约100ms，加上服务端压缩耗时（约5~10ms）和浏览器解压耗时（约5ms），总时间从400ms降到120ms，提升约70%。
- 大量API调用：后台接口返回50KB的JSON数据，压缩至10KB，在慢网络（512kbps）下，传输时间从约800ms降到160ms，提升约80%，在高速网络（50Mbps）下，传输时间差异缩小（从8ms降至2ms）,但仍能节省带宽。
- 带宽受限场景（如移动端、跨国访问）：Gzip的加速效果尤为突出，体积缩小70%，意味着用户等待时间缩短70%以上。
注意：极小的资源（如几百字节）不建议压缩，因为压缩头和解压开销可能抵消收益，通常阈值设为1~10KB。
副作用：CPU开销可控，收益远大于成本
开启Gzip会增加服务端压缩和客户端解压的CPU开销,但对于现代服务器和浏览器：
- 服务端压缩一次资源（或开启缓存）后，后续请求直接读取压缩后的文件,CPU负担极低。
- 浏览器解压速度极快，远快于网络传输时间，实测中，解压1MB文本仅需几毫秒到十几毫秒,而传输该体积的时间可能长达数秒。
CPU开销几乎可忽略，而网络传输加速带来的用户体验提升则是颠覆性的。
适用场景与配置建议
- 必须开启的场景：HTTP响应头中配置
Content-Encoding: gzip，作用于所有静态文本资源（HTML/CSS/JS/JSON/字体/SVG等）。 - 不建议开启的场景：已压缩的图片（JPEG、PNG、GIF、WebP）、视频（MP4、WebM）、PDF等,压缩几乎无效且浪费CPU。
- 配置级别：建议使用Gzip的默认压缩级别（如6），平衡压缩比与速度，级别过高（如9）效果提升不大,CPU开销却成倍增加。
一个立竿见影的优化策略
- 体积缩小：文本资源减少60%~80%，大JSON可压缩90%以上。
- 速度提升：慢网络下加载时间缩短50%~80%,快网络下也能节省带宽。
- 成本极低：CPU开销微乎其微，配置简单（在Nginx、Apache、CDN中均可一键开启）。
如果你的网站或API尚未开启Gzip，这是成本最低、见效最快的性能优化之一，只需一行配置，就能让用户感受到“秒开”的体验提升。
