Nginx 压缩缓存与静态资源加速
1. 先理解这件事
很多站点看起来“慢”，并不是因为业务逻辑复杂，而是因为：
- 静态资源太大
- 浏览器重复下载
- Nginx 没把自己最擅长的加速能力用起来
对新手来说，最先该掌握的是三件事：
- 开启压缩，减少传输体积
- 设置缓存，让浏览器少重复请求
- 让静态资源尽量直接由 Nginx 处理
对有经验的读者，更值得关注的是：
- 哪些类型适合压缩，哪些不适合
- 缓存策略如何和构建产物的 hash 命名配合
- 如何避免错误缓存导致发布后资源不更新
2. 最小可用配置
http {
gzip on;
gzip_types text/plain text/css application/javascript application/json image/svg+xml;
gzip_min_length 1024;
server {
listen 80;
server_name example.com;
location /assets/ {
root /var/www/app;
expires 30d;
add_header Cache-Control "public, max-age=2592000";
}
}
}这段配置可以先这样理解：
gzip on;开启压缩gzip_types指定要压缩的内容类型expires 30d;和Cache-Control用于让浏览器缓存静态资源
3. 先从最简单的优化做起
新手先记住这条主线：
- HTML、CSS、JS、JSON 这些文本类资源通常值得压缩。
- 已经高度压缩过的二进制资源，不一定适合再压缩。
- 构建产物如果带内容哈希，就更适合长缓存。
这意味着：
- 不要一上来对所有资源一刀切
- 要先区分“适合压缩”和“适合缓存”的对象
4. 更稳妥的缓存思路
比较常见的做法是区分两类资源：
index.html这类入口文件，缓存时间短一些- 带 hash 的静态资源，缓存时间长一些
原因很简单：
- 入口文件要尽快感知新版本发布
- 带 hash 的资源文件名变了就代表内容也变了，适合长期缓存
5. 常见误区
5.1 所有文件都长缓存
这样很容易导致页面发布后，用户仍然拿到旧入口文件或旧资源。
5.2 把图片、视频等都强行开启 gzip
这类资源很多已经是压缩格式，再压缩收益通常有限。
5.3 只开缓存，不看实际命中效果
缓存策略配置了不代表真的生效，还是要结合浏览器响应头和访问日志验证。
6. 实践建议
- 静态资源尽量通过 Nginx 直接服务，不要无意义透传到应用层。
- 文本类资源优先开启 gzip。
- 缓存策略要和前端构建产物命名规则一起设计。
- 调整后用浏览器 DevTools 和访问日志验证命中情况。
7. 排查清单
- 已开启 gzip 且类型配置合理
- 已为静态资源设置明确缓存策略
- 已区分入口文件与带 hash 资源的缓存规则
- 已验证压缩和缓存头是否真正生效