![c8942d80c0308311079e6e1a55ce1e08.png](https://img-blog.csdnimg.cn/img_convert/c8942d80c0308311079e6e1a55ce1e08.png)
前言
随着前端工程化的开发方式日益完善,像 webpack、rollup、gulp 等工具已经融入到我们的日常开发之中。最常见的就是 webpack ,一个模块打包工具。
但随着项目的功能需求迭代,代码量越来越多,原先构建时没有暴露的问题现在倍数级放大。
你能想象改个 css、js 文件整个项目的构建居然要从原先的几秒到如今的半分钟,甚至更多时间,简直无法忍受,严重影响工作效率。
这篇文章将使用两个工具来让你定位是什么原因导致那么长的构建时间。
webpack-bundle-analyzer
webpack-bundle-analyzer 是个 webpack 可视化分析工具。利用 webpack-bundle-analyzer 可以看到项目中所有模块体积大小的分布。
环境准备
它的安装、集成到现有项目非常容易。挂载到 webpack 对应的 plugin 选项中即可。
![bf3744dcd5a00dc18601ff04157fda6b.png](https://img-blog.csdnimg.cn/img_convert/bf3744dcd5a00dc18601ff04157fda6b.png)
运行
随着你启 webpack 的构建完成,最后它将默认启动一个 http://127.0.0.1:8888 来显示分析好的可视化页面。
因为它内置会有个 server ,所以不需要我们添加额外的服务。
结果分析
![820b4a2917fb3d6d964b4223bf076112.png](https://img-blog.csdnimg.cn/img_convert/820b4a2917fb3d6d964b4223bf076112.png)
从上图的 Treemap 中,我们就能看到项目中所有的模块的体积大小,以及每个模块中的内含关系。
你可以点开这张图,大致能得到如下这些信息:
- 每个 chunks 很大,最大的一个甚至有 943 kb,平均也都 600 kb 以上
- 每个 chunks 模块,都内含一个 jquery 文件,并且 css 也占有一定的比重
- 所有 chunks 的个数非常多,总共有 50 多个
webpack 自带 profile 分析
环境准备
相比前者工具,这个 profile 分析器是 webpack 内置的,我们只要在运行命令后添加相关参数即可。
![5adfc806c03eabefc45778287c6c9247.png](https://img-blog.csdnimg.cn/img_convert/5adfc806c03eabefc45778287c6c9247.png)
最后它会在项目中,生成一个 profile.json 。
结果分析
我们只要把它上传到 webpack 分析的网站机会得到一份报表。
http://webpack.github.io/analyse/#home
下面我就截图核心的几个图,来重点看下:
![2dc1b1572928d60ffa03f7e653ba5f35.png](https://img-blog.csdnimg.cn/img_convert/2dc1b1572928d60ffa03f7e653ba5f35.png)
概览
![5d0a175871cb79f7ec47297b04294f37.png](https://img-blog.csdnimg.cn/img_convert/5d0a175871cb79f7ec47297b04294f37.png)
模块引用
![cf4c7f84559c151ab26c1c250e5665db.png](https://img-blog.csdnimg.cn/img_convert/cf4c7f84559c151ab26c1c250e5665db.png)
模块引用&大小
![dc41792c504d504421087d43fec0879a.png](https://img-blog.csdnimg.cn/img_convert/dc41792c504d504421087d43fec0879a.png)
大模块
同样根据上面 4 张图的展示,就能得出如下信息:
- 所使用的 webpack 版本为 3.12.0
- 总模块高达 300 多个,chunks 54 个
- 模块 modules 被多个 chunks 共同引用
- 几乎每个 chunks 都引用 jquery 文件,总体积占到了 11 M
- scss 编译时间占用过多
结论
通过 webpack-bundle-analyzer 和 webpack profile 展示的信息基本能分析出几个拖慢构建速度的原因:
- 项目入口 entry 文件过多,导致 chunks 有 54 个
- 每个 chunk 引用模块重复率很高,没有公共模块的提取
- jquery 和部分业务 js 体积过大被打包到最终的结果中
- scss 编译,占用了部分时间,是整个编译有个长时间的等待
- webpack 版本可以考虑升级
这就是接下来可以考虑优化的几个方向。如果有兴趣,可以看下:
webpack 优化:6 种方式让构建时间达到秒级
我是怎么让近一分钟的构建,变成几秒。
关于我
一位“前端工程师”,乐于实践,并分享前端开发经验。
如果有问题或者想法,欢迎各位评论留言,愿大家共同进步。
关注【前端雨爸】,查阅更多前端技术心得。