前端资源压缩实战：减小体积提升加载性能的高效方案
萌新.焕焕资源压缩这事，我踩过太多坑了
最近重构一个老项目，打包体积大得离谱，首屏加载慢得像蜗牛。老板问“能不能再快点”，我只能苦笑。其实资源压缩这事，说简单也简单，说复杂也复杂——工具一堆，配置五花八门，但真用起来，坑比想象中多得多。今天就来聊聊我在实际项目中用过的几种压缩方案，不讲理论，只讲实战体验。
谁更省事？Webpack 自带的 Terser 还是 Brotli？
先说结论：**日常开发我首选 Webpack + Terser，上线部署再加一层 Brotli 压缩**。为什么？因为省心。
Terser 是 Webpack 默认的 JS 压缩器（从 v4 开始替代了 UglifyJS），开箱即用。你基本不用额外配置，只要在 mode: 'production' 下，它就会自动把你的代码压缩、混淆、删除注释。比如这段代码：
// 未压缩前
function greetUser(name) {
if (name) {
console.log("Hello, " + name + "!");
} else {
console.log("Hello, guest!");
}
}经过 Terser 处理后，可能变成：
function greetUser(n){n?console.log("Hello, "+n+"!"):console.log("Hello, guest!")}够狠吧？但关键在于——它几乎不会出错。我用过两年多，没遇到过一次压缩导致功能异常的问题（前提是别乱关掉 compress 里的安全选项）。
不过，Terser 只能压 JS。CSS 和 HTML 怎么办？这时候很多人会引入 css-minimizer-webpack-plugin 或 html-webpack-plugin 的 minify 选项。但说实话，这些插件配置起来有点啰嗦，而且压缩率提升有限。所以我一般只对 JS 做深度压缩，CSS/HTML 交给服务器层处理。
而 Brotli 就不一样了。它是 Google 推的压缩算法，比 Gzip 压缩率高 15%-30%，但**需要服务器支持**。Nginx 从 1.11.6 开始原生支持，配置也不难：
brotli on;
brotli_comp_level 6;
brotli_types text/plain text/css application/json application/javascript text/xml application/xml;但问题来了：本地开发怎么测？CI/CD 怎么生成 .br 文件？很多团队卡在这一步。我之前在一个项目里折腾了两天，最后发现——如果你们的 CDN（比如 Cloudflare）已经支持 Brotli，那根本不用自己生成 .br 文件！CDN 会自动在传输时压缩。所以，别自己造轮子，先问运维或看 CDN 文档。
性能对比：差距比我想象的大
我拿一个真实项目做了测试：一个 React SPA，未压缩 JS 约 1.2MB。
- 仅 Terser：压缩到 420KB
- Terser + Gzip：约 110KB
- Terser + Brotli：约 85KB
别小看这 25KB 的差距——在弱网环境下，首屏加载时间能差 300ms 以上。用户感知非常明显。
但这里有个陷阱：Brotli 压缩级别越高，构建时间越长。我试过 level 11，本地打包直接卡死 2 分钟。后来妥协用 level 6，压缩率和 level 9 差不多，但速度快了 5 倍。所以，**别盲目追求最高压缩率，平衡构建时间和收益更重要**。
我的选型逻辑
现在我基本按这个流程走：
- 开发阶段：关闭所有压缩，保证调试体验
- 生产构建：用 Webpack + Terser 压 JS，CSS 用
cssnano（通过mini-css-extract-plugin集成） - 部署阶段：让 Nginx 或 CDN 同时提供 Gzip 和 Brotli 响应（Brotli 优先）
为什么不全用 Brotli？因为有些老浏览器（比如 IE11）不支持。虽然现在 IE 用户少得可怜，但万一客户非要兼容呢？所以服务端必须同时保留 Gzip 回退。
另外，图片压缩我单独处理——用 image-minimizer-webpack-plugin 配合 Sharp，比 Webpack 内置的方案快得多。但注意：**别在 CI 里跑图片压缩**！Sharp 依赖 native 模块，CI 环境经常编译失败。我现在的做法是：开发时手动压缩一次，提交到 Git，构建时跳过图片压缩。
代码示例（Webpack 配置片段）：
// webpack.prod.js
const TerserPlugin = require("terser-webpack-plugin");
const CssMinimizerPlugin = require("css-minimizer-webpack-plugin");
module.exports = {
optimization: {
minimizer: [
new TerserPlugin({
terserOptions: {
compress: {
drop_console: true, // 我习惯线上删 console
pure_funcs: ["console.log"] // 更安全的删法
},
mangle: true,
},
}),
new CssMinimizerPlugin(),
],
},
};这里重点提醒：drop_console: true 虽然爽，但万一线上要 debug 怎么办？所以我会配合一个开关，比如通过环境变量控制是否保留 console。或者更稳妥的做法——用 pure_funcs 只删 console.log，保留 console.error。
踩坑提醒：这三点一定注意
1. **别在压缩时破坏第三方库**。有些库（比如某些加密 SDK）依赖特定的函数名或变量名，Terser 的 mangle 一开就炸。解决办法：在 terserOptions 里加 keep_fnames: true，或者用 exclude 跳过特定 chunk。
2. **Brotli 文件别手动生成**。我见过有人写脚本遍历 dist 目录，用 brotli 命令行工具生成 .br 文件。结果每次构建都要多等 1 分钟，还容易漏文件。正确的做法是：让服务器动态压缩，或者用 compression-webpack-plugin 在构建时生成（但注意配置 test 和 threshold）。
3. **Source Map 别忘关**。生产环境如果开了 source map，不仅体积大，还会泄露源码。我见过一次事故：source map 没关，黑客直接还原出整个业务逻辑。所以，devtool: false 必须写死在生产配置里。
最后说句实在话
资源压缩不是银弹。有时候你压到极致，用户还是觉得慢——因为瓶颈在接口、在图片、在渲染逻辑。我建议先用 Lighthouse 跑个分，看具体哪项拖后腿。如果是“未压缩资源”警告，再回头优化压缩策略。
以上是我个人对资源压缩方案的完整总结，有更优的实现方式欢迎评论区交流。毕竟前端这行，永远有更好的解法，只是我们还没遇到罢了。
