Vue-cli 项目构建优化
Vue-cli 项目构建优化分析、实践、经验总结。
分析手段
1.终端观察
2.审查项目的 webpack 配置
vue inspect --mode development > webpack.config.development.js
vue inspect --mode production > webpack.config.production.js
该命令会将解析出来的 webpack 配置 输出到指定的文件
3.speed-measure-webpack-plugin 分析各个插件和loader的解析耗时
4.webpack-bundle-analyzer 分析包大小
相关工具
speed-measure-webpack-plugin
这个插件可以测量网页包构建速度,并会输出各个模块编译的时长,可以帮助我们更好的找到耗时模块。
安装
npm i speed-measure-webpack-plugin -D
配置
在 vue.config.js 配置
const SpeedMeasurePlugin = require('speed-measure-webpack-plugin');
module.exports = {
...,
configureWebpack: (config) => {
...
config.plugins.push(
new SpeedMeasurePlugin(),
);
},
};
重新启动,即可看到各模块编译耗时
webpack-bundle-analyzer
生成代码分析报告,可以直观地分析打包出的文件有哪些,及它们的大小、占比情况、各文件 Gzipped 后的大小、模块包含关系、依赖项等。
(新版的Vue Cli 不用安装该插件,可直接执行yarn build:report
)
安装
# NPM
npm install --save-dev webpack-bundle-analyzer
# Yarn
yarn add -D webpack-bundle-analyzer
配置
const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;
module.exports = {
...,
configureWebpack: (config) => {
...
config.plugins.push(
new BundleAnalyzerPlugin()
);
},
};
thread-loader
多进程打包。文档:https://webpack.docschina.org/loaders/thread-loader/
使用时,需将此 loader 放置在其他 loader 之前。放置在此 loader 之后的 loader 会在一个独立的 worker 池中运行。
在 worker 池中运行的 loader 是受到限制的。例如:
这些 loader 不能生成新的文件。
这些 loader 不能使用自定义的 loader API(也就是说,不能通过插件来自定义)。
这些 loader 无法获取 webpack 的配置。
每个 worker 都是一个独立的 node.js 进程,其开销大约为 600ms 左右。同时会限制跨进程的数据交换。
注意:仅在耗时的操作中使用 thread-loader,否则使用 thread-loader 会后可能会导致项目构建时间变得更长,因为每个 worker 都是一个独立的 node.js 进程,其开销大约为 600ms 左右,同时还会限制跨进程的数据交换等。
安装
npm install --save-dev thread-loader
module.exports = {
module: {
rules: [
{
test: /\.js$/,
include: path.resolve('src'),
use: [
"thread-loader",
// 耗时的 loader (例如 babel-loader)
],
},
],
},
};
实践
总体效果
优化前:首次构建75s,二次构建43s
优化后:首次构建30s,二次构建3s
优化步骤
通过观察终端初步分析,主要原因是配置了插件 MinChunkSizePlugin影响构建期间的代码分析。
配置的CompressionWebpackPlugin 也有会影响,但在项目里据观察影响不多。
Webpack.optimize.MinChunkSizePlugin 插件用于设置模块的最小体积。它确保生成的 chunk 大小不会低于指定的大小。这可以用来避免生成过小的 chunk,从而优化资源加载性能。这个配置可能会增加编译时间。设置一个较大的 minChunkSize 值会导致Webpack在生成代码块时更加倾向于生成较大的代码块,这意味着Webpack可能需要更多时间来分析和决定如何合并模块以满足这一要求。因此,增大了代码块的最小大小可能会导致更复杂的代码拆分和合并过程,从而增加了整体的编译时间。
(通俗理解:合并小chunk、达到减少请求数量作用)
CompressionWebpackPlugin 插件,它的作用是在构建过程中对指定类型的文件进行 gzip 压缩,并生成对应的 .gz 文件,以减小文件体积,提高加载速度。配置中的参数包括压缩的文件类型、压缩阈值、压缩比例等。压缩文件会增加构建过程的时间消耗,因为在构建过程中需要额外的时间来进行压缩操作。压缩文件的大小和数量越多,构建过程所需的时间就会相应增加。
通过移除MinChunkSizePlugin 、CompressionWebpackPlugin 配置,
首次构建:75秒 > 30秒
二次构建:43秒 > 2.5秒
执行vue inspect --mode production > webpack.config.production.js
审查 webpack配置
发现默认开启了vue-loader、babel-loader的缓存,但没使用多线程编译:
使用speed-measure-webpack-plugin插件分析耗时,对耗时比较长的loader配置多线程编译
注意问题
1.vue-loader使用thread-loader打包会报错,暂时没定位到原因
通用思路
1.cache-loader 使用缓存,提升二次构建速度
2.多进程打包
thread-loader 是官方提供的一个可以利用多进程加速 loader 执行的 loader
3.缩小构建范围
4.关闭source-map
5.DLLPlugin
是 webpack 官方提供的一个插件,也是用来分离代码的,和 optimization.splitChunks有异曲同工之妙
6.webpack-parallel-uglify-plugin 多进程压缩JS(主要用于生产环境)
7.IgnorePlugin 避免引入无用模块
8.noParse 减少解析
9.MinChunkSizePlugin合并细小代码块 减少请求
-
使用缓存(vue-cli默认已使用)
使用命令vue-cli-service inspect
查看 vue-cli 内置的配置内容
其中一块内容表示,配置使用了cache-loader和babel-loader来处理JavaScript和JSX文件。cache-loader位于指定的目录中进行缓存,而babel-loader负责实际的转译工作。
文档: https://cli.vuejs.org/zh/guide/cli-service.html#vue-cli-service-inspect -
parallel多线程打包
parallel是vuecli提供的配置,默认开启,但仅作用于生产构建
文档:https://cli.vuejs.org/zh/config/#parallel