压缩与缓存头：两行配置省一半带宽

gzip 三行起步

http {
    gzip on;
    gzip_comp_level 5;              # 1-9，5 是性价比拐点
    gzip_min_length 1k;             # 小于 1K 不值得压
    gzip_types text/plain text/css application/json
               application/javascript application/xml;
    # 注意：text/html 默认就在压缩列表里，写不写无所谓
    # 但 css/js/json 必须显式加——这是"开了 gzip 但 JS 没压缩"的头号原因
    gzip_vary on;                   # 响应加 Vary: Accept-Encoding，给 CDN 看
}

验证方式：curl -H "Accept-Encoding: gzip" -I https://example.com/app.js，响应头出现 Content-Encoding: gzip 才算生效。浏览器 DevTools 的 Network 面板里，Size 列会同时显示原始大小和传输大小——两个数字差距大说明压缩在工作。

别压缩的东西

图片（jpg/png/webp）、视频、字体、压缩包——它们本身就是压缩格式，再压一遍 CPU 白烧、体积几乎不变，甚至更大。gzip_types 里千万别手痒把 image/* 加进去。另外注意压缩的代价：CPU 换带宽——级别 9 的压缩比 5 只小几个百分点，CPU 消耗却翻倍；低配机器上高压缩级别反而拖慢所有响应。

强缓存：让回头客零流量

强缓存的语义是"浏览器自己说了算"：响应头带 Cache-Control: max-age=31536000 或 expires，有效期内浏览器连请求都不发，直接用本地副本。配套前提是上一篇讲的指纹文件名——内容变则文件名变，旧缓存自然失效，"缓存一年"与"发版即更新"靠这个机制同时成立。入口 index.html 则反着配：add_header Cache-Control "no-cache";——每次都问一句"有没有新版"。

协商缓存：过期了也未必重新下载

协商缓存的收益在"没变就 304"：响应体不传，只剩一个状态码——几百字节的往返代替几 MB 的下载。Nginx 对静态文件默认就开了这两种协商缓存，基本不用配；真正要动脑的是缓存策略的分层设计：什么资源强缓存、什么资源协商、什么资源绝不缓存。

带宽账本

把三件事叠起来算一笔账：HTML 不缓存（几 KB）→ CSS/JS/图片强缓存一年（第二次访问 0 流量）→ 首次访问 gzip 压缩（体积 30%）。一个日活十万的站点，仅压缩一项每月就能省下 TB 级流量——配置层面最大的性能杠杆，往往就这两行。流量省下来了，下一篇讲怎么把恶意流量挡在门外：限流。