配了三年 pako，今天发现浏览器把 gzip 彻底原生化了——这件事把前端压缩的账全变了

还在 import pako 做 gzip 压缩？这件事，今天被浏览器自己彻底收了。

Chrome 80 / Safari 16.4 / Firefox 113 先后稳定支持了 CompressionStream API——浏览器把原生 zlib 引擎直接暴露给了 JavaScript。gzip / deflate / deflate-raw 三个格式，和服务端完全兼容。

把 pako 换成原生，产出完全一样：

// Before
import pako from “pako”;
const compressed = pako.gzip(jsonString);

// After
const compressed = await compress(jsonString);

Wire Format 没变，CDN 和 API 都不需要改。

实战一：IndexedDB 存大 JSON

200KB 的 JSON，gzip 压缩后 15-30KB。移动端存储配额受限的场景直接受益：

async function putCompressed(store, key, data) {
const compressed = await compress(JSON.stringify(data));
return store.put(compressed, key);
}

async function getCompressed(store, key) {
const compressed = await store.get(key);
if (!compressed) return null;
return JSON.parse(await decompress(compressed));
}

实战二：Web Worker 异步压缩

CompressionStream 原生支持 Web Worker，压缩任务放后台，主线程零阻塞：

// worker.js
self.onmessage = async ({ data }) => {
const compressed = await compress(JSON.stringify(data.payload));
self.postMessage({ compressed }, [compressed.buffer]);
};

pako 还能用吗？能。但理由变了。

pako 是纯 JS 实现（~45KB 打包体积），CompressionStream 调用的是浏览器底层 C 代码 zlib——和 HTTP 响应解压缩同一个引擎。Benchmark（Node v24，1MB 输入）：

• gzip-pako：~13 ops/sec
• gzip-node zlib（即 CompressionStream 同款）：~30+ ops/sec

大文件（100KB+）原生快 3-10 倍。小文件（<10KB）差别可忽略。

对比：

• CompressionStream：0 打包体积、C 引擎 3-10x JS、Worker 原生、Baseline 2022+
• pako：~15KB gzipped、纯 JS v8、可用但有开销、IE 都能跑

下一步：现在就能迁

不需要全量重写。兼容性判断：if (“CompressionStream” in window)，不兼容的才用 pako 兜底。绝大多数 2022 年后的现代项目，直接走第一个分支。

之前靠 pako 续命的场景，浏览器自己会了，而且跑得更快、打包更小。