vue webpack项目打包优化,从60s到17s的优化之路
下面就进入本文的正题了:对本文感兴趣的,想必都有一定的开发经验了,对webpack工具也有了一定的了解。只是在webpack生态里面有太多的插件了,除了默认推荐的插件之外,不知道怎么找更好用的插件,其实当初,我也有和你一样的困惑,只是我喜欢钻研,喜欢尝试。基于webpack的项目啦都有一个弊端,项目体积越大,打包耗时越长。下面就把我优化项目的案例展示给你。激动么~~~Vue项目比较大.或...
下面就进入本文的正题了:
对本文感兴趣的,想必都有一定的开发经验了,对webpack工具也有了一定的了解。只是在webpack生态里面有太多的插件了,除了默认推荐的插件之外,不知道怎么找更好用的插件,其实当初,我也有和你一样的困惑,只是我喜欢钻研,喜欢尝试。基于webpack的项目啦都有一个弊端,项目体积越大,打包耗时越长。下面就把我优化项目的案例展示给你。激动么~~~
Vue 项目比较大.或者说项目中引入了许多第三方库,那么在执行 npm run build 构建项目的时候会极其的慢.比如我现在的项目就每次打包就要大概60s的样子,打包出来的项目文件大概36M左右。
下面就是我整理的一些优化技巧,可以有效地提高打包速度。
我希望你可以根据每一步完成之后都运行npm run build打包一下,比较下每步的构建时长。
一、配置 resolve.modules
1,优化原理
(1)webpack 的 resolve.modules 是用来配置模块库(即 node_modules)所在的位置。当 js 里出现 import 'vue' 这样不是相对、也不是绝对路径的写法时,它便会到 node_modules 目录下去找。
(2)在默认配置下,webpack 会采用向上递归搜索的方式去寻找。但通常项目目录里只有一个 node_modules,且是在项目根目录。为了减少搜索范围,我们可以直接写明 node_modules 的全路径。
2,操作步骤
(1)打开 build/webpack.base.conf.js 文件,添加如下配置:
module.exports = {
resolve: {
extensions: [
'.js'
,
'.vue'
,
'.json'
],
modules: [
resolve(
'src'
),
resolve('node_modules')
],
alias: {
'vue$'
:
'vue/dist/vue.esm.js'
,
'@'
: resolve(
'src'
),
}
},
二、配置装载机的 include & exclude
1,优化原理
(1)webpack 的装载机(loaders)里的每个子项都可以有 include 和 exclude 属性:
- include:导入的文件将由加载程序转换的路径或文件数组(把要处理的目录包括进来)
- exclude:不能满足的条件(排除不处理的目录)
(2)我们可以使用 include 更精确地指定要处理的目录,这可以减少不必要的遍历,从而减少性能损失。
(3)同时使用 exclude 对于已经明确知道的,不需要处理的目录,予以排除,从而进一步提升性能。
2,操作步骤
(1)打开 build/webpack.base.conf.js 文件,添加如下配置:
module: {
rules: [
{
test: /\.vue$/,
loader:
'vue-loader'
,
options: vueLoaderConfig,
include: [resolve(
'src'
)
],
exclude: /node_modules\/(?!(autotrack|dom-utils))|vendor\.dll\.js/
},
{
test: /\.js$/,
loader:
'babel-loader'
,
include: [resolve(
'src'
)],
exclude: /node_modules/
},
(2)保存后再次构建项目,可以发现时间又缩短了 2s 左右。
三、使用 webpack-parallel-uglify-plugin 插件来压缩代码
1,优化原理
(1)默认情况下 webpack 使用 UglifyJS 插件进行代码压缩,但由于其采用单线程压缩,速度很慢。
(2)我们可以改用 webpack-parallel-uglify-plugin 插件,它可以并行运行 UglifyJS 插件,从而更加充分、合理的使用 CPU 资源,从而大大减少构建时间。
2,操作步骤
(1)执行如下命令安装 webpack-parallel-uglify-plugin
|
|
(2)打开 build/webpack.prod.conf.js 文件,并作如下修改:
const ParallelUglifyPlugin = require(
'webpack-parallel-uglify-plugin'
);
//....
// 删掉webpack提供的UglifyJS插件
//new UglifyJsPlugin({
// uglifyOptions: {
// compress: {
// warnings: false
// }
// },
// sourceMap: config.build.productionSourceMap,
// parallel: true
//}),
// 增加 webpack-parallel-uglify-plugin来替换
new
ParallelUglifyPlugin({
cacheDir:
'.cache/'
,
uglifyJS:{
output: {
comments:
false
},
compress: {
warnings:
false
}
}
}),
(3)保存后再次构建项目,可以发现时间又缩短了 10s 左右。
四、使用 HappyPack 来加速代码构建
1,优化原理
(1)由于运行在 Node.js 之上的 Webpack 是单线程模型的,所以 Webpack 需要处理的事情只能一件一件地做,不能多件事一起做。
(2)而 HappyPack 的处理思路是:将原有的 webpack 对 loader 的执行过程,从单一进程的形式扩展多进程模式,从而加速代码构建。
2,操作步骤
(1)执行如下命令安装 happypack:
1 |
|
(2)打开 build/webpack.base.conf.js 文件,并作如下修改:
const HappyPack = require(
'happypack'
);
const os = require(
'os'
);
const happyThreadPool = HappyPack.ThreadPool({ size: os.cpus().length });
module.exports = {
module: {
rules: [
{
test: /\.js$/,
//把对.js 的文件处理交给id为happyBabel 的HappyPack 的实例执行
loader:
'happypack/loader?id=happyBabel'
,
include: [resolve(
'src'
)],
//排除node_modules 目录下的文件
exclude: /node_modules/
},
]
},
plugins: [
new
HappyPack({
//用id来标识 happypack处理那里类文件
id:
'happyBabel'
,
//如何处理 用法和loader 的配置一样
loaders: [{
loader:
'babel-loader?cacheDirectory=true'
,
}],
//共享进程池
threadPool: happyThreadPool,
//允许 HappyPack 输出日志
verbose:
true
,
})
]
}
(3)保存后再次构建项目,可以发现时间又缩短到了17s左右。打包出来的项目文件只有7M多了(忘记截图了)。
扣个666!!!
你的构建时长有没有减少到一半以上啦,有的话就恭喜你了。看看你打包出来的项目文件是不是也小了许多。
有时候需要重复构建一下,才能看到大的变化。
》》》你是不是在打包前还在手动删除dist文件???
解决方法:安装, npm i clean-webpack-plugin -D
然后修改webpack.prod.conf.js文件:
const CleanWebpackPlugin = require("clean-webpack-plugin");
plugins: [
new CleanWebpackPlugin(["dist"], {}),//把代码加在此处,每次构建前都会自动删除dist文件
至此构建优化的就全部结束了!!!
对webpack比较熟悉的的朋友可以不看下面的内容。
webpack是现代前端开发中最火的模块打包工具,只需要通过简单的配置,便可以完成模块的加载和打包。那它是怎么做到通过对一些插件的配置,便可以轻松实现对代码的构建呢?
webpack的配置详解
const path = require('path');
module.exports = {
entry: "./app/entry", // string | object | array
// Webpack打包的入口
output: { // 定义webpack如何输出的选项
path: path.resolve(__dirname, "dist"), // string
// 所有输出文件的目标路径
filename: "[chunkhash].js", // string
// 「入口(entry chunk)」文件命名模版
publicPath: "/assets/", // string
// 构建文件的输出目录
/* 其它高级配置 */
},
module: { // 模块相关配置
rules: [ // 配置模块loaders,解析规则
{
test: /.jsx?$/, // RegExp | string
include: [ // 和test一样,必须匹配选项
path.resolve(__dirname, "app")
],
exclude: [ // 必不匹配选项(优先级高于test和include)
path.resolve(__dirname, "app/demo-files")
],
loader: "babel-loader", // 模块上下文解析
options: { // loader的可选项
presets: ["es2015"]
},
},
},
resolve: { // 解析模块的可选项
modules: [ // 模块的查找目录
"node_modules",
path.resolve(__dirname, "app")
],
extensions: [".js", ".json", ".jsx", ".css"], // 用到的文件的扩展
alias: { // 模块别名列表
"module": "new-module"
},
},
devtool: "source-map", // enum
// 为浏览器开发者工具添加元数据增强调试
plugins: [ // 附加插件列表
// ...
],
}
从上面我萌可以看到,webpack配置中需要理解几个核心的概念 Entry
、 Output
、 Loaders
、 Plugins
、 Chunk
- Entry:指定webpack开始构建的入口模块,从该模块开始构建并计算出直接或间接依赖的模块或者库
- Output:告诉webpack如何命名输出的文件以及输出的目录
- Loaders:由于webpack只能处理javascript,所以我萌需要对一些非js文件处理成webpack能够处理的模块,比如sass文件
- Plugins:
Loaders
将各类型的文件处理成webpack能够处理的模块,plugins
有着很强的能力。插件的范围包括,从打包优化和压缩,一直到重新定义环境中的变量。但也是最复杂的一个。比如对js文件进行压缩优化的UglifyJsPlugin
插件 - Chunk:coding split的产物,我萌可以对一些代码打包成一个单独的chunk,比如某些公共模块,去重,更好的利用缓存。或者按需加载某些功能模块,优化加载时间。在webpack3及以前我萌都利用
CommonsChunkPlugin
将一些公共代码分割成一个chunk,实现单独加载。在webpack4 中CommonsChunkPlugin
被废弃,使用SplitChunksPlugin
好了,写了一天写累了,喝杯茶休息一下,感觉的可以继续关注我,后续还有很多干货更新啦!!!
谢谢你的拜读和支持!!!!
更多推荐
所有评论(0)