前端项目打包体积压缩实战对比与优化经验分享
优化前:卡得不行
最近接手了一个老项目,页面加载速度简直惨不忍睹。首页打开要5秒多,用户反馈说“卡得受不了”。尤其是图片和JS资源特别多,网络稍差一点就转圈转到怀疑人生。
最让人头疼的是,这个项目用了很多第三方库,代码体积非常大。打包后的vendor.js居然有3MB!这谁顶得住啊。
找到瓶颈了!
既然是性能问题,那肯定得先定位原因。我试了几种工具,最后还是Chrome DevTools最好用。
在Network面板里一看,果然是资源体积太大了。特别是几个关键的JS文件,每个都在几百KB以上。我还用了Lighthouse跑了一下性能分析,得分只有可怜的30分,主要扣分项就是“减少未使用的JavaScript”和“启用文本压缩”。
这里要提醒一下,很多人只看Network面板就完事了,其实Performance面板也很重要。我录了一段页面加载过程,发现主线程被大量解析脚本的工作堵住了。
尝试几种压缩方案
知道了问题出在哪,就开始想办法优化了。我主要试了三种方案:
- Gzip压缩
- Brotli压缩
- Tree Shaking + Terser
第一种Gzip最简单,Nginx直接开启就行。但效果一般,只能压缩到原来的60%左右。
核心代码就这几行
最终效果最好的是Brotli+Terser的组合拳。Brotli是Google推出的新一代压缩算法,比Gzip效果更好,压缩率能到70%-80%。
服务器配置如下:
http {
brotli on;
brotli_comp_level 6;
brotli_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript image/svg+xml;
}
然后在Webpack配置里加上Terser插件:
const TerserPlugin = require('terser-webpack-plugin');
module.exports = {
optimization: {
minimize: true,
minimizer: [new TerserPlugin({
terserOptions: {
compress: {
drop_console: true, // 移除console
},
output: {
comments: false, // 移除注释
},
},
})],
},
};
这里踩了个坑,一开始没加drop_console,结果生产环境还带着一堆调试信息。后来加上这个选项,又少了几十KB。
优化后:流畅多了
改完之后效果立竿见影。vendor.js从3MB降到了700KB,整体页面加载时间从5秒降到800ms左右。Lighthouse跑分也涨到了85分。
不过说实在的,这个方案也不是完美的。Brotli虽然压缩率高,但是压缩时间比Gzip长不少。我们CI/CD流水线的打包时间从原来的2分钟增加到4分钟。还好这是可以接受的范围。
性能数据对比
这里列一下具体的数据对比:
- vendor.js:3MB → 700KB
- main.css:200KB → 45KB
- 首屏加载时间:5s → 800ms
- Lighthouse性能评分:30分 → 85分
另外要注意,Brotli在低版本浏览器上有兼容性问题。我加了个降级处理:
gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript image/svg+xml;
brotli on;
brotli_comp_level 6;
brotli_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript image/svg+xml;
总结一下
以上是我个人对压缩优化的一些实战经验。Brotli配合Terser确实效果显著,但也要考虑打包时间和兼容性问题。如果你的项目也在被大文件困扰,建议试试这个方案。
当然,性能优化是个系统工程,除了压缩还有很多其他手段。比如懒加载、CDN加速、HTTP/2等等。这些内容以后有机会再分享。
有更好的实现方式欢迎评论区交流,或者你也有类似的踩坑经历,咱们可以一起讨论。

暂无评论