前端资源压缩和传输优化有哪些手段？
简化版
资源优化分三层：构建期用 minify、Tree Shaking 和媒体转码减少原始内容；传输期由 Accept-Encoding/Content-Encoding 协商 gzip、br 或受支持编码；交付层用 CDN、内容 hash 与缓存避免远距离和重复传输。已经压缩的 JPEG、视频、zip 通常不应再做通用压缩，JS 还必须看解析执行成本。
详细版
HTML、CSS、JS、JSON、SVG 等文本通常适合 gzip/Brotli；静态资源可在构建或部署时预压缩，避免每次请求消耗 CPU。服务端要按 Accept-Encoding 选择表示，并让共享缓存区分编码变体。
Brotli 常能提供较好文本压缩率，gzip 兼容成熟；现代 HTTP 也定义 zstd 等编码，但采用要依据客户端、CDN和服务器实际支持，不能只改响应头。已压缩媒体再次编码收益低，甚至可能变大。
下载体积与执行成本不同。1 MB 源码压成 250 KB 后，浏览器仍要解压、解析并执行相应逻辑，所以还要拆包、延迟非关键代码和减少初始化。
完整版教学
一、先区分源码缩减与 HTTP 内容编码
Minify、Tree Shaking、图片转码会改变构建产物本身；HTTP 内容编码则在传输表示上压缩，浏览器解码后得到原资源。两层可以叠加，但解决的问题不同。
源码 1.5MB ─minify/tree shake→ app.js 700KB
─Content-Encoding: br→ 网络传输 180KB
─浏览器解码/解析/执行→ 仍处理 700KB 代码记忆钩子：构建压缩减少“内容”，传输压缩减少“路上字节”，拆包减少“当前必须处理的内容”。
二、协商编码时请求与响应各说什么
浏览器用 Accept-Encoding 声明可接受编码及偏好，服务器选择一种并在 Content-Encoding 标注。Content-Type 仍描述解码后的媒体类型，二者不能混淆。
GET /app.js
Accept-Encoding: gzip, br, zstd
HTTP/1.1 200 OK
Content-Type: text/javascript
Content-Encoding: br
Vary: Accept-Encoding共享缓存必须区分不同编码表示，通常依赖正确的 Vary: Accept-Encoding 或 CDN 内部等价机制。只写 Content-Encoding: br 却返回未编码字节，会使浏览器解码失败，不是性能优化。
三、gzip、Brotli 与新编码怎样取舍
gzip 成熟、支持广、编码速度与压缩率平衡；Brotli 对文本静态资源常有更好压缩率，高质量级别的实时编码可能较耗 CPU。Zstandard 等现代编码也进入 HTTP 生态，但端到端支持和缓存配置要实测。
| 编码 | 常见优势 | 主要取舍 |
|---|---|---|
| gzip | 兼容成熟、动态响应常用 | 压缩率通常不如合适的 br |
| br | 文本压缩率常较好 | 高级别编码 CPU 成本高 |
| zstd | 解压/压缩性能有吸引力 | 客户端/CDN支持需验证 |
| identity | 无编码 | 大文本浪费带宽 |
面试中用“Brotli 通常更小”比“永远小 20%”准确。压缩率取决于内容、字典、级别和已最小化程度，必须由实际文件测量。
四、预压缩为什么适合内容 hash 静态资源
app.abc123.js 内容不变，可以在 CI 一次生成 .br 与 .gz，CDN 根据请求返回合适版本。它把昂贵压缩计算从每次请求移到构建阶段，并保持响应延迟稳定。
假设动态 Brotli 每次消耗 25ms CPU，日请求 100 万次就是约 25,000 CPU 秒；预压缩只在构建时执行一次，回源和边缘节点直接读文件。代价是制品存储增加和部署配置更复杂。
HTML 或 API 动态响应可用较低成本实时压缩，但过小响应压缩头和 CPU 可能超过节省。服务器通常设置最小体积阈值，并根据负载选择级别。
五、哪些内容不该重复压缩
JPEG、AVIF、WebP、MP4、woff2、zip 等通常已有专用压缩，再套 gzip/br 常收益极低甚至体积增加，还浪费 CPU。对它们应从分辨率、码率、格式和分段传输优化。
| 类型 | 通用内容编码 | 更关键手段 |
|---|---|---|
| JS/CSS/HTML/JSON | 通常值得 | minify、拆包、缓存 |
| SVG | 通常值得 | 简化路径、移除元数据 |
| JPEG/AVIF/WebP | 通常不值得 | 尺寸、质量、格式 |
| 视频/音频 | 通常不值得 | 编码码率、自适应流 |
HTTPS 压缩还要注意敏感反射内容与秘密共同压缩可能形成侧信道的安全历史问题。安全敏感响应应按威胁模型设计，不能为了省字节无条件压缩所有内容。
六、CDN、缓存与代码执行形成完整链路
CDN 把缓存副本靠近用户，减少 RTT 与源站负载；内容 hash 静态资源可长期 immutable，HTML 及时重新验证。缓存命中时节省的是整个请求传输，不只是压缩比例。
假设 700 KB JS 经 br 为 180 KB，在 2 Mbps 下纯传输从约 2.8 秒降到 0.72 秒；但命中本地强缓存时网络可接近 0。即便缓存命中，首次使用仍可能有解析执行，因此代码分割和运行时治理仍必要。
工程验证要同时看 Network 的 transfer size、decoded/body size、Content-Encoding、cache status 与主线程脚本耗时。CDN 报“已开启 Brotli”不代表每条资源实际返回了 br。
七、常见误区与追问
- 误区：压缩后 JS 很小就一定执行很快。 传输字节减少，解压后的代码仍要解析、编译和执行。
- 误区：所有文件都应该开启 gzip 或 Brotli。 已压缩媒体通常收益低，还会浪费 CPU。
- 误区：响应写了 Content-Encoding 就代表压缩正确。 字节必须按该编码生成，缓存也要区分表示。
- 追问：静态资源为什么适合预压缩？ 内容不变，可一次高质量编码、多次直接复用，避免实时 CPU 成本。
- 追问：Brotli 是否永远优于 gzip？ 不保证，需考虑内容、压缩级别、编码成本与端到端支持。
- 追问：Vary: Accept-Encoding 有什么作用？ 防止共享缓存把一种编码的表示错误返回给不匹配客户端。
- 追问：怎样验证 CDN 压缩真的生效？ 检查实际响应头、transfer/decoded size、缓存命中和不同 Accept-Encoding 请求。
八、加强记忆
用“构建减内容、协商减字节、缓存免传输、拆包减首屏、性能看执行”串起答案：文本选择端到端支持的 gzip/br 等编码，hash 静态资源优先预压缩，媒体用自身格式优化；CDN 与缓存避免重复成本，但 JavaScript 最终仍要解析执行，所以不能把网络压缩当成全部性能优化。