1、资源压缩基础：为什么需要压缩？常见压缩算法概览（Gzip、Brotli、Zstd）

大家好，我是这门课的主讲。今天咱们聊聊资源压缩。

你可能觉得压缩不就是把文件变小吗？嗯，对，也不全对。我做了这么多年前端，见过太多因为没做好压缩导致的性能事故。说白了，压缩是网络传输的「减负神器」，也是用户体验的「隐形守护者」。

1.1 为什么需要压缩？

你想想看，一个网页加载慢，用户会等吗？不会。Google 的数据显示，页面加载时间超过 3 秒，53% 的用户会直接走人。而压缩，就是让页面变快最直接的手段之一。

举个例子。一个 300KB 的 JavaScript 文件，不压缩直接传输，在 4G 网络下可能要 2 秒。但用 Gzip 压缩后，可能只剩 80KB，传输时间降到 0.5 秒。这差距，用户能明显感觉到。

我在项目中遇到过一件事。有一次上线一个活动页面，图片和 JS 都没压缩，结果用户反馈加载慢得像蜗牛。后来我加了 Gzip 压缩，首屏时间从 4.2 秒降到了 1.8 秒。嗯，从那以后，压缩就成了我上线的「必检项」。

1.2 常见压缩算法概览

目前主流的压缩算法有三个：Gzip、Brotli、Zstd。它们各有千秋，适用场景也不同。我整理了一张对比表，方便你快速了解。

算法	推出时间	压缩比	压缩速度	解压速度	浏览器支持
Gzip	1992	中等	快	快	所有浏览器
Brotli	2015	高	较慢	快	现代浏览器
Zstd	2015	高	极快	极快	有限（需 CDN 或后端支持）

1.3 Gzip：老牌王者

Gzip 是资历最老的压缩算法。从 1992 年到现在，它几乎成了 Web 压缩的默认标准。所有浏览器都支持，所有服务器都能配。

它的原理是基于 Deflate 算法，说白了就是找重复的字符串，然后用更短的标记替换。对于文本类资源（HTML、CSS、JS），效果非常明显。

我个人习惯在 Nginx 里这样配：

gzip on;
gzip_types text/plain text/css application/javascript application/json;
gzip_min_length 1024;
gzip_comp_level 6;
gzip_vary on;

1.4 Brotli：后起之秀

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

不过 Brotli 有个小缺点：压缩速度比 Gzip 慢。但解压速度很快，所以适合静态资源的预压缩。我建议在构建阶段就把文件压好，而不是让服务器实时压缩。

举个例子，用 Brotli 压缩一个 React 打包后的 JS 文件：

# 安装 brotli 工具
npm install -g brotli

# 压缩文件
brotli --quality 11 --input build/static/js/main.abc123.js --output build/static/js/main.abc123.js.br

1.5 Zstd：新锐力量

Zstd（Zstandard）是 Facebook 开发的算法。它的特点是压缩和解压速度都极快，而且压缩率可以灵活调整。在需要实时压缩的场景下，Zstd 是首选。

不过 Zstd 在浏览器端的支持还比较有限。目前主要用在 CDN 节点之间、服务端缓存、以及一些高性能场景。比如 Cloudflare 的 CDN 就用 Zstd 来压缩边缘节点之间的数据传输。

我个人觉得，Zstd 是未来的趋势。随着浏览器支持的完善，它可能会取代 Gzip 和 Brotli。但现在，我们还是以 Gzip 和 Brotli 为主。

1.6 知识体系总览

下面这张图，帮你理清本章的核心逻辑。

1.7 如何选择？

没有最好的算法，只有最合适的。我一般这样选：

• 静态资源（HTML、CSS、JS） —— 用 Brotli 预压缩，Gzip 做降级
• API 响应 —— 用 Gzip 或 Zstd，因为需要实时压缩
• CDN 节点间传输 —— 用 Zstd，速度快，延迟低
• 老项目维护 —— 只用 Gzip，省心省力