用途：JavaScript 是页面体积与请求量仅次于图片的资源，压缩可减少脚本在网络中的传输时间，进而改善页面加载性能。本技能适合需要减小 JS 载荷、优化网络传输时间（尤其面向较慢连接用户）的场景，建议与最小化、代码分割、缓存策略配合使用。
主要能力与建议：优先使用 Brotli 而非 Gzip，在相近速度下获得更好压缩比；对不常变化的资源使用静态压缩，对频繁变化内容使用动态压缩；在服务器或 CDN 层启用压缩（如 Nginx、Vercel、Netlify）；压缩前先最小化 JavaScript；注意粒度权衡——较大的打包压缩效果更好，但较小的分块缓存效果更好。JavaScript 应使用无损压缩，因为它需要浏览器上完整可执行的有效代码。
技术细节：Gzip 基于 Deflate（LZ77 加 Huffman 编码），所有主流浏览器支持，Zopfli 是其较慢但更优的版本，适合静态压缩。Brotli 由 Google 于 2015 年推出，同样基于 LZ77 与 Huffman 编码，并额外使用二阶上下文建模、更大的回溯窗口和静态字典，主流服务器与浏览器及 Netlify、AWS、Vercel 均支持。Chrome 研究建议：Gzip 9 在良好速度下压缩率最佳；Brotli 考虑 6-11 级；Brotli 9-11 优于 Gzip 但较慢；打包越大压缩率与速度越好。
启用方式：可在构建中静态压缩，如 Webpack 的 CompressionPlugin（Gzip）或 BrotliWebpackPlugin（Brotli）；Next.js 默认提供 Gzip 但建议在 Nginx 等 HTTP 代理启用；Vercel 在代理层支持两者。动态压缩可在支持的服务器（含 Node.js）启用，浏览器通过 Accept-Encoding 请求头声明支持算法（如 gzip, br），服务器返回 Content-Encoding 响应头（如 br）。Express 提供 compression 中间件。
审计：可在 Chrome DevTools → Network → Headers 查看服务端是否压缩下载的脚本或文本；Lighthouse 的“Enable Text Compression”性能审计会检查未设置 br、gzip 或 deflate 的文本类资源，并用 Gzip 估算潜在节省。
限制与权衡：压缩与缓存、去重目标存在冲突：compress(a + b) <= compress(a) + compress(b)，即单个大包比多个小包压缩更好，但小分块缓存更佳，且代码变更时只需重新下载受影响分块。多数生产应用目前最大分块数约为 10，这一上限需提升以支持大量 JavaScript 的更好缓存与去重；较小分块有利于缓存，但依赖应就绪并避免下载执行多余代码。具体服务器配置步骤与命令资料未提供。