1. 资源压缩概述：为什么需要资源压缩？常见压缩算法简介

大家好，欢迎来到《资源压缩与UI事件处理》的第一章。今天咱们聊聊一个看似基础、但实际坑特别多的话题——资源压缩。

先问大家一个问题：你写的前端页面，或者后端接口返回的数据，真的「瘦」下来了吗？我见过太多项目，上线前只想着功能跑通，结果首屏加载慢得像蜗牛爬。嗯，这里要说的就是资源压缩。

说白了，压缩就是为了让数据「变小」。变小之后，传输更快、存储更省、带宽压力更小。你想想看，一个 1MB 的 JSON 接口，压缩到 200KB，用户打开页面的速度能快多少？

我在项目中遇到过最典型的场景：一个后台管理系统，接口返回的列表数据动不动就几百 KB。没做压缩前，用户每次翻页都要等 3-4 秒。后来上了 Gzip，直接降到 1 秒以内。用户反馈从「这系统真慢」变成了「还行嘛」。

具体来说，资源压缩能带来三个核心收益：

核心观点：压缩不是「锦上添花」，而是「雪中送炭」。尤其在高并发、低带宽的场景下，压缩是必须做的优化手段。

市面上压缩算法不少，但真正在生产环境广泛使用的，其实就三个：Gzip、Brotli、Zstd。我按自己的使用经验，给大家捋一捋。

Gzip 诞生于 1992 年，算得上是压缩界的「老兵」了。几乎所有 Web 服务器、浏览器都支持它。你打开任何一个主流网站，十有八九都在用 Gzip。

它的压缩原理是 LZ77 + Huffman 编码。简单说，就是找重复的字符串，用更短的标记替换。比如「ababab」这种模式，Gzip 能识别出来并压缩。

优点：兼容性极好，部署简单。Nginx 里加一行 gzip on; 就完事。

缺点：压缩率一般，对文本类资源能压到 30%-50%，但对图片、视频等二进制文件效果很差。

我的习惯：静态资源（HTML、CSS、JS、JSON）必开 Gzip。图片和视频就别想了，它们本身已经是压缩格式，再压也没意义。

Brotli 是 Google 在 2015 年推出的算法。它的压缩率比 Gzip 高 20%-30%，尤其对文本类资源效果更好。为什么？因为它内置了 HTML、CSS、JS 的常用字典，能更聪明地找到重复模式。

我在项目中做过对比：一个 500KB 的 JavaScript 文件，Gzip 压缩后是 150KB，Brotli 能压到 110KB。差了 40KB，对于移动端来说，这就是 1-2 秒的加载时间差距。

优点：压缩率更高，尤其适合文本资源。

缺点：浏览器兼容性稍差（IE 不支持），压缩速度比 Gzip 慢一点（但解压速度差不多）。

避坑指南：我曾经在生产环境直接全量切 Brotli，结果发现 IE 用户拿不到压缩资源，接口返回乱码。后来加了 Accept-Encoding 判断，才搞定。建议 Brotli 和 Gzip 同时开启，让浏览器自己选。

Zstd（Zstandard）是 Facebook 在 2016 年开源的算法。它的特点是「快」——压缩和解压速度都远超 Gzip 和 Brotli，同时压缩率也不差。

Zstd 支持「压缩级别」调节，从 1 到 22。级别越低，速度越快，压缩率越低；级别越高，压缩率越高，但速度变慢。实际生产中，我常用级别 3 或 5，平衡速度和压缩率。

优点：速度快、压缩率好、可调节级别。

缺点：浏览器原生不支持（需要 JS 解码），主要用于服务端内部通信、数据存储、日志压缩等场景。

一句话总结：Web 前端用 Brotli + Gzip 双保险；后端服务间通信、大数据存储用 Zstd；老项目图省事直接用 Gzip。

为了方便大家选型，我整理了一张对比表。这张表是我自己项目里实测出来的，不是网上随便抄的。

特性	Gzip	Brotli	Zstd
诞生年份	1992	2015	2016
压缩率（文本）	中等（约 30%-50%）	高（比 Gzip 高 20%-30%）	高（接近 Brotli）
压缩速度	中等	较慢（级别越高越慢）	快（级别 3 时极快）
解压速度	快	快	极快
浏览器支持	全部	主流浏览器（Chrome、Firefox、Edge、Safari）	不支持（需 JS 解码）
典型场景	Web 静态资源、API 响应	Web 静态资源（替代 Gzip）	服务端通信、数据存储、日志

为了让大家对本章内容有个整体印象，我画了一张结构图。它展示了资源压缩的核心逻辑：从「为什么需要压缩」到「用什么算法」，再到「如何选型」。

这一章我们聊了资源压缩的必要性，以及三种主流算法的特点。我个人建议：别纠结选哪个，先让压缩跑起来。哪怕只用 Gzip，也比不压缩强 10 倍。