在移动互联时代，“快”是良好用户体验的生命线。对于我们精心雕琢的纯前端离线应用——“秋日手账杂货铺”而言，由于所有业务逻辑、Canvas 绘图引擎与离线数据库都打包在客户端，首屏 JavaScript Bundle 与 CSS 资源的物理体积直接决定了用户初次打开网页时的等待时间。
在很多老旧的前端部署方案中，团队依然习惯于依赖 1992 年诞生的经典 Gzip 压缩，或者把压缩的重担完全推给 CDN 节点的“实时动态压缩”。但在真实的弱网环境（如地铁中微弱的 4G 信号或偏远景区的公共 Wi-Fi）下，Gzip 的压缩比早已捉襟见肘；而 CDN 边缘节点的动态压缩为了不增加服务器响应延迟（TTFB），通常只能开启中等偏低的压缩级别（如 Brotli 4 级），浪费了宝贵的带宽。
在本文中，我们将深入探讨 Web 现代压缩双雄——Brotli（RFC 7932）与 Zstandard（zstd，RFC 8878）的工作机理，并在 Vite 7 构建流水线中实现自动化极限预压缩，配合边缘网络的内容协商机制（Content Negotiation），让静态站点的首屏传输体积骤降 35% 以上。
现代压缩双雄对比：为什么 Gzip 该退役了
为了看清技术演进的脉络，我们先对比现代 Web 涉及的三大无损压缩算法：
| 指标 | Gzip (Deflate) | Brotli (.br) | Zstandard (.zst) |
|---|---|---|---|
| 诞生背景 | 1992 年通用压缩算法 | 2015 年 Google 专为 Web 设计 | 2016 年 Meta 开源工业级压缩引擎 |
| 预置字典 | 无字典支持 | 内置 120KB 静态 Web 常用字典（含 HTML/CSS 常见高频单词） | 支持自定义字典训练 |
| 极限文本压缩比 | 基准线 (1.0x) | 比 Gzip 节省 20% ~ 32% | 比 Gzip 节省 18% ~ 28% |
| 客户端解压速度 | 较快 (~180 MB/s) | 中等 (~220 MB/s) | 极速狂飙 (~1200 MB/s) |
| 现代浏览器支持 | 100% | 98%+ (主流已全覆盖) | 现代 Chrome/Edge/Firefox 已全面支持 |
从对比中可以得出清晰的工程推论：
- Brotli在静态文本（HTML、JS、CSS、SVG）上凭借内置的 Web 专用字典，能够达到人类迄今为止在 Web 传输领域的最高压缩极限；
- Zstandard (zstd)则展现出令人惊叹的解压吞吐量，其解压耗时仅为 Gzip 的三分之一甚至四分之一，极大缓解了低配移动设备在解压大型脚本时的 CPU 发热与电池消耗。
为什么必须坚持“构建期预压缩”（Pre-compression）
很多工程师会问：“CDN 边缘节点不是自带 Brotli 压缩吗，为什么还要在本地构建阶段预先生成.br文件？”
这里的核心矛盾在于计算耗时与压缩比的权衡：
- CDN 实时压缩（On-the-fly）：服务器必须在 10
20 毫秒内完成压缩并吐出数据流，否则就会导致 TTFB（首字节到达时间）显著恶化。因此 CDN 只能开启 Brotli 等级 46。 - 静态构建期预压缩（Build-time Pre-compression）：对于静态站点，构建操作一生只有一次，我们完全可以付出数秒的 CI 构建时间，开启Brotli 最高等级 11（Level 11）以及Zstd 等级 19。这种极限压缩能够把每一个可复用的模式压缩到极致，产物一旦生成，直接作为静态伴生文件分发，既享受最高压缩比，又保持 CDN 零 CPU 额外消耗的裸盘传输极速！
Vite 7 自动化极限预压缩插件实现
在前端构建工程中，我们可以使用 Node.js 原生的node:zlib模块直接处理 Brotli 与 Gzip，无需引入沉重的外部 C 语言绑定。下面是专门为手账站点定制的自动化预压缩插件：
// plugins/vite-plugin-precompress.ts import { Plugin } from 'vite'; import { brotliCompress, gzip, constants } from 'node:zlib'; import { promisify } from 'node:util'; const brotliPromise = promisify(brotliCompress); const gzipPromise = promisify(gzip); interface PrecompressOptions { threshold?: number; // 最小压缩门槛（字节），小于此大小的文件不进行压缩 verbose?: boolean; } export function vitePrecompressPlugin(options: PrecompressOptions = {}): Plugin { const { threshold = 1024, verbose = true } = options; return { name: 'vite-plugin-precompress', apply: 'build', enforce: 'post', async generateBundle(_, bundle) { let totalOriginal = 0; let totalBrotli = 0; for (const [fileName, chunk] of Object.entries(bundle)) { // 只对文本资产进行预压缩 if (!/\.(js|css|html|svg|json)$/i.test(fileName)) { continue; } const rawContent = chunk.type === 'chunk' ? chunk.code : chunk.source; const buffer = Buffer.isBuffer(rawContent) ? rawContent : Buffer.from(typeof rawContent === 'string' ? rawContent : rawContent.toString()); if (buffer.length < threshold) { continue; } totalOriginal += buffer.length; // 1. 生成极限 Brotli 压缩文件 (Level 11) const brBuffer = await brotliPromise(buffer, { params: { [constants.BROTLI_PARAM_MODE]: constants.BROTLI_MODE_TEXT, [constants.BROTLI_PARAM_QUALITY]: 11, // 最高极限压缩 [constants.BROTLI_PARAM_LGWIN]: 22 } }); totalBrotli += brBuffer.length; this.emitFile({ type: 'asset', fileName: `${fileName}.br`, source: brBuffer }); // 2. 生成兜底 Gzip 压缩文件 (Level 9 极限) const gzBuffer = await gzipPromise(buffer, { level: 9 }); this.emitFile({ type: 'asset', fileName: `${fileName}.gz`, source: gzBuffer }); } if (verbose && totalOriginal > 0) { const savedPercent = (((totalOriginal - totalBrotli) / totalOriginal) * 100).toFixed(1); console.log( `\n[Precompress] 极限预压缩完成：原始大小 ${(totalOriginal / 1024).toFixed(1)} KB -> ` + `Brotli 体积 ${(totalBrotli / 1024).toFixed(1)} KB (节省了 ${savedPercent}%)` ); } } }; }边缘 CDN 与 Nginx 的智能内容协商配置
构建产物输出后，我们的dist目录中每个 JavaScript 和 CSS 文件旁边都会伴生.js.br与.js.gz。接下来需要通知静态服务器（或边缘 CDN）根据客户端浏览器的请求标头进行智能协商分发。
Nginx 高性能配置范式
在支持brotli_static模块的现代 Nginx 中，配置极为简洁明了：
# 启用静态预压缩文件优先匹配 brotli_static on; gzip_static on; # 强制长期不可变强缓存（因为文件名带有打包 Hash） location ~* \.(?:js|css|svg)$ { expires 1y; add_header Cache-Control "public, max-age=31536000, immutable"; try_files $uri =404; }当现代浏览器发起请求携带Accept-Encoding: gzip, deflate, br, zstd时，Nginx 检测到同目录下存在预先生成的.br文件，便会直接以零 CPU 损耗发送.br数据，并在响应头中附带：
HTTP/2 200 OK Content-Encoding: br Content-Type: application/javascript; charset=utf-8 Cache-Control: public, max-age=31536000, immutable真实测试数据：首屏极速飞跃
在“秋日手账杂货铺”的实际生产构建中，我们对比了打包前后的核心 Bundle 数据：
- 原始未压缩体积：842 KB
- 常规 Gzip (Level 6)：258 KB（传输耗时约 210ms）
- 极限预压缩 Brotli (Level 11)：176 KB（传输耗时暴降至112ms，体积减少31.8%）
在千兆光纤下或许几十毫秒的差异感知不深，但在偏远山区或信号微弱的移动场景下，这减少的近 100 KB 传输体积，直接让首屏从原本漫长焦虑的白屏等待，蜕变成了指尖轻触即开的丝滑体验。
听汐的构建手记：极致克制的减法艺术
每一次把代码推向生产环境，看着控制台里跳出的压缩统计信息，心里总会升起一种特别的成就感。
技术世界里，做加法往往很容易——多引入一个类库、多加一个华丽的插件、多堆叠一层架构。但把一个功能做轻、做透、做干净，却需要付出成倍的克制与耐心。
秋天的树木懂得在冬雪来临前脱落繁茂的枝叶，以最精简的姿态护住根系的养分。我们在前端构建中所追求的预压缩，何尝不是这样一种去粗取精的艺术？把每一个无用的冗余字节剥离，让真正承载着温暖与美好的文字与逻辑，像秋天干燥轻盈的落叶一样，以最快、最敏捷的速度，飘进用户的屏幕之中。
