Optimize the construction speed of nextjs webpack
使用工具
speed-measure-webpack-plugin
测算打包过程中各plugin,loader所耗费的时间
webpack-bundle-analyzer
分析打包出来的各资源大小,方便对过大的包进行优化
提速方案
cache-loader
效果
原理
公共模块提取
autodll-webpack-plugin
dll全称dynamic link library
,是微软率先提出的概念,译作动态链接库。
分别通过两个plugin
来运行
dllPlugin
进行构建资源文件,生成一个mainfest.json
字典,字典里存储模块与id的映射
dllRefrencePlugin
通过id对模块进行引入autodll-webpack-plugin
是对两个插件的整合,减少使用的复杂度。
原理
资源加载方式
vendor
不太好辨认,我们可以粘入控制台
其他模块同理,输入模块索引,获取对应模块。
打包缓存方式
- 缓存目录下
autodll-webpack-plugin
内存在production_instance_0_cda54207bafebb237a6e726378cf1b00
目录 - 存在
packge.json.hash
- 当前
packge.json
和packge.json.hash
对比无有变化
若不满足上述条件,就会重新写入packge.json.hash
对比dll方式和spiltChunks方式
可参考这个问题
webpack-common-chunks-plugin-vs-webpack-dll-plugin
因为在模块打包方式上,dll需要手动声明需要打入一起的模块
1 |
|
而spiltChunks
可以自由定义模块提取的最小引用
,最小体积
,以及正则匹配
,功能更加强大智能。
(需要webpack4及以上才能使用,低版本可用commonChunkPlugin
替代)
模块分布
优化前
优化后
资源体积大小
优化前
优化后
打包耗时
优化前
优化后
接入方式
因为nextjs
内置了webpack
打包脚本,所以我们要在外侧复写
内置配置 ![image.png](data:image/gif;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVQImWNgYGBgAAAABQABh6FO1AAAAABJRU5ErkJggg==)
复写
在next.config.js
中进行配置
1 |
|
测试
ci打包速度测试
可用性测试
增量
存量更新
改变标签颜色)
其他优化思路
提升依赖查找速度
webpack对模块的搜索本质上是遍历资源树
提升loader解析速度
loader要对对应扩展名的文件进行解析,遍历,替换,例如babel-loader
提高插件处理速度
插件对代码的压缩和混淆,cpu会是速度的瓶颈
好消息是next
内置配置都从这三个方面进行了优化,让笔者轻松了不少。
知识拓展
IgnorePlugin
一个可忽略包中某些资源的库,比如moment.js
中的时区信息
方式是使用正则匹配
modules-with-no-loaders
使用speed-measure-webpack-plugin时发现有些模块未被loader处理
因为存在loader
需要exclude
的模块,比如node_modules
里的三方包,已经经过相应loader转换,我们不必再进行处理,这样可以提高loader
转换速度,是正常的
如果modules-with-no-loaders
耗时较长,可能是引入的库比较多导致的。