2026 年了很多构建脚本还在gzip -9一把梭——因为行业里流传一个印象brotli 太慢只配在 CI 里预压缩动态/构建期压缩不敢用。但我在同一台机器、同一份 2MB 的 JS 产物上把 gzip、deflate、brotli 各档拉到一起实测结果有点反直觉brotli 开到 6 档编码比 gzip -9 快 3.2 倍压完还小 2.7%。brotli 慢 这个标签可能只贴对了第 11 档。背景为什么这件事值得写构建产物JS、CSS、JSON、source map本质都是文本压缩是性价比最高的优化之一零代码改动、直接砍传输体积和 CDN 账单。gzip 基于 Deflate 算法是 1990 年代就定下的默认brotli 是 Google 2015 年推出的内置一份针对 HTML/CSS/JS 的静态字典文本上天然占优。2026 年几篇压缩选型文章给出的共识是brotli-11 压缩率最高但极慢约 0.5–1 MB/s只适合构建时预压缩动态内容用 brotli-4~6 或退回 gzip。这条建议本身没错但brotli 整体慢的模糊印象让不少团队干脆不在构建/CI 里用 brotli默认gzip -9了事。本文不炒共识而是用 Node 内置zlib在同一环境、同一份语料上把 gzip / deflate / brotli 的 1~11 档统一测一遍看慢到底指哪一档、甜点到底在哪。解剖gzip 和 brotli 到底差在哪先拆一个最容易混淆的点gzip 和 deflate 的压缩率完全一样。gzip 就是 zlib 的 deflate 流外面套了一层 10~18 字节的头部和 CRC 校验多出来的只是包装不影响压缩本身。所以本文里gzip-9和deflate-9的输出字节数会几乎相同区别仅在解码时的头部开销。brotli 的不同在于它带一份静态字典常见 HTML 标签、CSS 属性、JS 关键字对 web 文本能多挤出几个百分点。两者都靠档位level在编码速度和压缩率之间做权衡——这是本次实测的两个核心变量编码速度MB/s / 毫秒决定构建、CI、动态压缩的 CPU 成本压缩率ratio决定传输体积、存储、CDN 账单解码速度只有在请求侧浏览器 / 服务端解压才重要跑一次测一下即可。真正要判断的是为了多压几个百分点值得多花多少编码时间。实证一次真实数据主语料js_2mb是一份2,097,152 字节约 2.0 MB的类 minified JS重复 token 随机标识符压缩友好度接近真实打包产物。所有配置在同一 Node v22 进程内跑编码取 5~9 轮中位warmup 一次排除 JIT 抖动。配置输出大小压缩率编码耗时编码速度与 gzip-9 比gzip-9573 KB3.576×138.3 ms14.5 MB/s基准deflate-9573 KB3.577×138.1 ms14.5 MB/s同率仅多 18B 包装brotli-4581 KB3.525×17.8 ms112 MB/s7.8× 快略大 1.4%brotli-6558 KB3.673×43.4 ms46 MB/s3.2× 快小 2.7%brotli-9544 KB3.765×114.0 ms17.6 MB/s1.2× 快小 5.3%brotli-11484 KB4.230×1908.7 ms1.05 MB/s13.8× 慢小 18.4%图1横轴是编码速度MB/s越右越快纵轴是压缩率越高越好。右下方的 brotli-6 同时落在更快且更高压缩率区域——它就是甜点brotli-11 压缩率最高却在最左下是仅适合预压缩的慢档。结论很清楚brotli 在 4~9 档的编码速度都优于或仅略慢于gzip-9同时压缩率更好真正慢的只有第 11 档。所谓brotli 慢到只能用预压缩把 level-11 的特征错误地推广到了整个算法。解码侧完全不是问题同样 2MB 语料brotli 各档解码 4~6 msgzip 4 ms差异在噪声范围内即便放到 6MBbrotli-11 解码也只要 15.6 ms。请求侧解压不会成为瓶颈。复现这段基准只需要 Node无需任何依赖# 纯 Node 内置 zlib零外部包 node -e const zlibrequire(zlib); const bufBuffer.alloc(2*1024*1024, a).fill(function f(){return this.x}const y123;); for(const [a,l] of [[gzip,9],[deflate,9],[brotli,6],[brotli,11]]){ const t0performance.now(); const o abrotli ? zlib.brotliCompressSync(buf,{params:{[zlib.constants.BROTLI_PARAM_QUALITY]:l}}) : (agzip?zlib.gzipSync(buf,{level:l}):zlib.deflateSync(buf,{level:l})); const msperformance.now()-t0; console.log(al, (o.length/1024|0)KB, (buf.length/o.length).toFixed(3)x, ms.toFixed(1)ms); } 图26 个配置的编码速度柱状图。gzip-9 / deflate-9 都卡在 ~14.5 MB/sbrotli-6 冲到 46 MB/sbrotli-4 更是 112 MB/s唯一的深坑是 brotli-11 的 1.05 MB/s。速度维度和图1 的压缩率维度共同指向同一个甜点brotli-6。扩展6MB 与 4MB JSON 还成立吗单一语料可能是巧合再上两个量级/类型验证结论的稳健性。js_6mb6.0 MB 同类 JSbrotli-6 编码 31.1 MB/sgzip-9 只有 13.7 MB/s2.3× 快压缩率 3.649× vs 3.577×小 2.1%brotli-11 掉到 0.94 MB/s13.8× 慢但率升到 4.249×。趋势与 2MB 完全一致。json_4mb4.19 MB JSON这里出现一个有意思的分化——brotli-6 仍稳赢38.7 MB/s vs 27.9 MB/s1.4× 快率 3.323× vs 3.280×小 1.3%但brotli-9 在 JSON 上反而 14.4 MB/s比 gzip-9 慢 1.9×。也就是说brotli-9 比 gzip-9 还快 的优势只在 JS 这类高度冗余文本上成立换 JSON 就反转。图3在 js_2mb / js_6mb / json_4mb 三类语料上brotli-6紫对 gzip-9蓝的编码速度与压缩率双指标。速度维 brotli-6 三类全胜压缩率维也全胜或持平——brotli-6 是跨内容都稳的甜点brotli-9 则不是。一句话收束brotli-6 是稳健甜点brotli-9 的更快看内容brotli-11 是预压缩专属档。局限哪些事没解决实现绑定 Node zlib本文用的是 Node 内置的纯 JS/WASM 实现。系统brotli/gzipCLI、或 Rust 实现的 zstd多篇 2026 文章提到 zstd-3 比 gzip-6 快 5×会得到不同绝对值。结论适用于在 Node 构建/CI 流程内做压缩的场景。语料是合成的类是 minified JS / JSON真实业务包冗余度不同绝对数字会变但brotli-6 更快且更小、brotli-11 极慢的趋势一致。没测不该压的东西图片、woff2、视频等已压缩格式再压只会变大变慢小于约 150~300 字节的小文件因算法帧开销也会负优化构建脚本应跳过。单线程单核高并发动态压缩时brotli 编码器单实例约 16MB 内存占用要计入成本gzip 仅约 256KB——这点在动态压缩场景比速度更该被盯。结论与下一步brotli 慢是 level-11 的标签不是 brotli 的。落到工程实践上可复用的三条构建 / CI 内压缩直接上 brotli-6比gzip -9更快2~3×、更小2~5%、解码不拖请求没有理由再用纯 gzip。静态资源CSS/JS/JSON/map用 brotli-11 预压缩一次性编码成本运行时零开销配 nginxbrotli_static on直接落盘服务。动态内容 CPU 吃紧时退回gzip -6通用、内存占用小、解码最快brotli-9 别盲上它在 JSON 上比 gzip-9 还慢。把压缩档位当成速度—率的旋钮而不是非黑即白比记住brotli 慢这种标签有用得多。开源地址矩阵门户GitHub - wangzifan396-wzf/WB: nano-tools: 1310 single-file, zero-dependency, local-first web utilities in one portal. Offline and private, nothing leaves your browser. Binary protocol parsers, crypto, dev, audio, visualization, productivity. · GitHub单文件工具聚合器GitHub - wangzifan396-wzf/nano-workbench: Single-file tabbed launcher for the nano-tools matrix - one tab, 382 curated tools (of 1310), instant switching. Zero-dep. Part of nano-tools. · GitHubGitHub 组织主页wangzifan396-wzf (WangZi) · GitHub brotli 慢到只能预压缩？实测 brotli-6 比 gzip-9 快 3 倍、还多压 2.7%：构建产物压缩选型的实测复盘
2026 年了很多构建脚本还在gzip -9一把梭——因为行业里流传一个印象brotli 太慢只配在 CI 里预压缩动态/构建期压缩不敢用。但我在同一台机器、同一份 2MB 的 JS 产物上把 gzip、deflate、brotli 各档拉到一起实测结果有点反直觉brotli 开到 6 档编码比 gzip -9 快 3.2 倍压完还小 2.7%。brotli 慢 这个标签可能只贴对了第 11 档。背景为什么这件事值得写构建产物JS、CSS、JSON、source map本质都是文本压缩是性价比最高的优化之一零代码改动、直接砍传输体积和 CDN 账单。gzip 基于 Deflate 算法是 1990 年代就定下的默认brotli 是 Google 2015 年推出的内置一份针对 HTML/CSS/JS 的静态字典文本上天然占优。2026 年几篇压缩选型文章给出的共识是brotli-11 压缩率最高但极慢约 0.5–1 MB/s只适合构建时预压缩动态内容用 brotli-4~6 或退回 gzip。这条建议本身没错但brotli 整体慢的模糊印象让不少团队干脆不在构建/CI 里用 brotli默认gzip -9了事。本文不炒共识而是用 Node 内置zlib在同一环境、同一份语料上把 gzip / deflate / brotli 的 1~11 档统一测一遍看慢到底指哪一档、甜点到底在哪。解剖gzip 和 brotli 到底差在哪先拆一个最容易混淆的点gzip 和 deflate 的压缩率完全一样。gzip 就是 zlib 的 deflate 流外面套了一层 10~18 字节的头部和 CRC 校验多出来的只是包装不影响压缩本身。所以本文里gzip-9和deflate-9的输出字节数会几乎相同区别仅在解码时的头部开销。brotli 的不同在于它带一份静态字典常见 HTML 标签、CSS 属性、JS 关键字对 web 文本能多挤出几个百分点。两者都靠档位level在编码速度和压缩率之间做权衡——这是本次实测的两个核心变量编码速度MB/s / 毫秒决定构建、CI、动态压缩的 CPU 成本压缩率ratio决定传输体积、存储、CDN 账单解码速度只有在请求侧浏览器 / 服务端解压才重要跑一次测一下即可。真正要判断的是为了多压几个百分点值得多花多少编码时间。实证一次真实数据主语料js_2mb是一份2,097,152 字节约 2.0 MB的类 minified JS重复 token 随机标识符压缩友好度接近真实打包产物。所有配置在同一 Node v22 进程内跑编码取 5~9 轮中位warmup 一次排除 JIT 抖动。配置输出大小压缩率编码耗时编码速度与 gzip-9 比gzip-9573 KB3.576×138.3 ms14.5 MB/s基准deflate-9573 KB3.577×138.1 ms14.5 MB/s同率仅多 18B 包装brotli-4581 KB3.525×17.8 ms112 MB/s7.8× 快略大 1.4%brotli-6558 KB3.673×43.4 ms46 MB/s3.2× 快小 2.7%brotli-9544 KB3.765×114.0 ms17.6 MB/s1.2× 快小 5.3%brotli-11484 KB4.230×1908.7 ms1.05 MB/s13.8× 慢小 18.4%图1横轴是编码速度MB/s越右越快纵轴是压缩率越高越好。右下方的 brotli-6 同时落在更快且更高压缩率区域——它就是甜点brotli-11 压缩率最高却在最左下是仅适合预压缩的慢档。结论很清楚brotli 在 4~9 档的编码速度都优于或仅略慢于gzip-9同时压缩率更好真正慢的只有第 11 档。所谓brotli 慢到只能用预压缩把 level-11 的特征错误地推广到了整个算法。解码侧完全不是问题同样 2MB 语料brotli 各档解码 4~6 msgzip 4 ms差异在噪声范围内即便放到 6MBbrotli-11 解码也只要 15.6 ms。请求侧解压不会成为瓶颈。复现这段基准只需要 Node无需任何依赖# 纯 Node 内置 zlib零外部包 node -e const zlibrequire(zlib); const bufBuffer.alloc(2*1024*1024, a).fill(function f(){return this.x}const y123;); for(const [a,l] of [[gzip,9],[deflate,9],[brotli,6],[brotli,11]]){ const t0performance.now(); const o abrotli ? zlib.brotliCompressSync(buf,{params:{[zlib.constants.BROTLI_PARAM_QUALITY]:l}}) : (agzip?zlib.gzipSync(buf,{level:l}):zlib.deflateSync(buf,{level:l})); const msperformance.now()-t0; console.log(al, (o.length/1024|0)KB, (buf.length/o.length).toFixed(3)x, ms.toFixed(1)ms); } 图26 个配置的编码速度柱状图。gzip-9 / deflate-9 都卡在 ~14.5 MB/sbrotli-6 冲到 46 MB/sbrotli-4 更是 112 MB/s唯一的深坑是 brotli-11 的 1.05 MB/s。速度维度和图1 的压缩率维度共同指向同一个甜点brotli-6。扩展6MB 与 4MB JSON 还成立吗单一语料可能是巧合再上两个量级/类型验证结论的稳健性。js_6mb6.0 MB 同类 JSbrotli-6 编码 31.1 MB/sgzip-9 只有 13.7 MB/s2.3× 快压缩率 3.649× vs 3.577×小 2.1%brotli-11 掉到 0.94 MB/s13.8× 慢但率升到 4.249×。趋势与 2MB 完全一致。json_4mb4.19 MB JSON这里出现一个有意思的分化——brotli-6 仍稳赢38.7 MB/s vs 27.9 MB/s1.4× 快率 3.323× vs 3.280×小 1.3%但brotli-9 在 JSON 上反而 14.4 MB/s比 gzip-9 慢 1.9×。也就是说brotli-9 比 gzip-9 还快 的优势只在 JS 这类高度冗余文本上成立换 JSON 就反转。图3在 js_2mb / js_6mb / json_4mb 三类语料上brotli-6紫对 gzip-9蓝的编码速度与压缩率双指标。速度维 brotli-6 三类全胜压缩率维也全胜或持平——brotli-6 是跨内容都稳的甜点brotli-9 则不是。一句话收束brotli-6 是稳健甜点brotli-9 的更快看内容brotli-11 是预压缩专属档。局限哪些事没解决实现绑定 Node zlib本文用的是 Node 内置的纯 JS/WASM 实现。系统brotli/gzipCLI、或 Rust 实现的 zstd多篇 2026 文章提到 zstd-3 比 gzip-6 快 5×会得到不同绝对值。结论适用于在 Node 构建/CI 流程内做压缩的场景。语料是合成的类是 minified JS / JSON真实业务包冗余度不同绝对数字会变但brotli-6 更快且更小、brotli-11 极慢的趋势一致。没测不该压的东西图片、woff2、视频等已压缩格式再压只会变大变慢小于约 150~300 字节的小文件因算法帧开销也会负优化构建脚本应跳过。单线程单核高并发动态压缩时brotli 编码器单实例约 16MB 内存占用要计入成本gzip 仅约 256KB——这点在动态压缩场景比速度更该被盯。结论与下一步brotli 慢是 level-11 的标签不是 brotli 的。落到工程实践上可复用的三条构建 / CI 内压缩直接上 brotli-6比gzip -9更快2~3×、更小2~5%、解码不拖请求没有理由再用纯 gzip。静态资源CSS/JS/JSON/map用 brotli-11 预压缩一次性编码成本运行时零开销配 nginxbrotli_static on直接落盘服务。动态内容 CPU 吃紧时退回gzip -6通用、内存占用小、解码最快brotli-9 别盲上它在 JSON 上比 gzip-9 还慢。把压缩档位当成速度—率的旋钮而不是非黑即白比记住brotli 慢这种标签有用得多。开源地址矩阵门户GitHub - wangzifan396-wzf/WB: nano-tools: 1310 single-file, zero-dependency, local-first web utilities in one portal. Offline and private, nothing leaves your browser. Binary protocol parsers, crypto, dev, audio, visualization, productivity. · GitHub单文件工具聚合器GitHub - wangzifan396-wzf/nano-workbench: Single-file tabbed launcher for the nano-tools matrix - one tab, 382 curated tools (of 1310), instant switching. Zero-dep. Part of nano-tools. · GitHubGitHub 组织主页wangzifan396-wzf (WangZi) · GitHub