This time I will show you how to optimize webpack configuration and what are the precautions for optimizing webpack configuration. The following is a practical case, let's take a look.
The recent project has passed the busy infrastructure construction period, and it has gradually relaxed. I am going to record my recent webpack optimization measures, hoping to have the effect of reviewing the past and learning the new. The project uses vue family bucket, and the build configuration is improved based on vue-cli. Regarding the original webpack configuration, you can read this article vue-cli#2.0 webpack configuration analysis. The article basically explains each line of code in the file in detail, which will help you better understand webpack. After carefully summarizing, my optimization is basically based on the points circulated on the Internetexternals
Document addresshttps://doc.webpack-china.org/configuration/externals/
Prevent certain imported packages from being packaged into bundles, and instead obtain these external dependencies from the outside at runtime.CommonsChunkPlugin
Document address https://doc.webpack-china.org/plugins/commons-chunk-plugin/ The CommonsChunkPlugin plug-in is an optional function for creating an independent file (also called a chunk). This file includes multiple entry chunks. public module. By separating the common modules, the final synthesized file can be loaded once at the beginning and then stored in the cache for subsequent use. This brings speed improvements because the browser will quickly pull the common code out of the cache instead of loading a larger file every time a new page is accessed.resolve.alias
Document address https://doc.webpack-china.org/configuration/resolve/#resolve-alias Create aliases for import orrequire to make module importing easier. For example, some common modules located under the src/ folder:
However, through my own practice, the last three points are the most optimized for my own project. The article also mainly explains the following points in detail It turns out that the time required to package a project is basically about 40 seconds. How long will it take to go through the next three steps of optimization?1. Use dllplugin to precompile and reference
Why reference Dll in the first place? After browsing some articles on the Internet, I found that in addition to speeding up the build, using webpack's dll has another benefit. After the Dll is packaged, it exists independently. As long as the libraries it contains are not added, deleted, or upgraded, the hash will not change. Therefore, the online DLL code does not need to be updated frequently with version releases. Because Dll packages are basically independent library files, one characteristic of such files is that they do not change much. When we normally package these library files into an app.js, due to changes in other business files, the cache optimization of the build is affected, resulting in the need to go back to the npm package every time to findSo how to use Dll to optimize the project
First, create a dll
const webpack = require('webpack');
const path = require('path');
module.exports = {
entry: {
//你需要引入的第三方库文件
vendor: ['vue','vuex','vue-router','element-ui','axios','echarts/lib/echarts','echarts/lib/chart/bar','echarts/lib/chart/line','echarts/lib/chart/pie',
'echarts/lib/component/tooltip','echarts/lib/component/title','echarts/lib/component/legend','echarts/lib/component/dataZoom','echarts/lib/component/toolbox'],
},
output: {
path: path.join(dirname, 'dist-[hash]'),
filename: '[name].js',
library: '[name]',
},
plugins: [
new webpack.DllPlugin({
path: path.join(dirname, 'dll', '[name]-manifest.json'),
filename: '[name].js',
name: '[name]',
}),
]
};webpack -p --progress --config build/webpack.dll.config.js
接下去你只要去你的webpack配置文件的里的plugin中添加一行代码就ok了。
const manifest = require('./dll/vendor-manifest.json');
...
...,
plugin:[
new webpack.DllReferencePlugin({
context: dirname,
manifest,
}),
]这时候再执行webpack命令，可以发现时间直接从40秒锐减到了20s左右，整整快了一倍有木有(不知道是不是因为自己依赖库太多了才这样的，手动捂脸)。
2.happypack多线程编译
一般node.js是单线程执行编译，而happypack则是启动node的多线程进行构建，大大提高了构建速度。使用方法也比较简单。以我项目为例,在插件中new一个新的happypack进程出来，然后再使用使用loader的地方替换成对应的id
var HappyPack = require('happypack');
...
...
modules:{
rules : [
...
{
test: /\.js$/,
loader:[ 'happypack/loader?id=happybabel'],
include: [resolve('src')]
},
...
]
},
...
...
plugin:[
//happypack对对 url-loader,vue-loader 和 file-loader 支持度有限，会有报错，有坑。。。
new HappyPack({
id: 'happybabel',
loaders: ['babel-loader'],
threads: 4,//HappyPack 使用多少子进程来进行编译
}),
new HappyPack({
id: 'scss',
threads: 4,
loaders: [
'style-loader',
'css-loader',
'sass-loader',
],
})
]这时候再去执行编译webpack的代码，打印出来的console则变成了另外一种提示。而编译时间大概从20s优化到了15s左右(感觉好像没有网上说的那么大，不知道是不是因为本身js比重占据太大的缘故)。
3.善用alias
3.配合resolve，善用alias
本来是没有第三点的，只不过在搜索网上webpack优化相关文章的时候，看到用人提到把引入文件改成库提供的文件(原理我理解其实就是1.先通过resolve指定文件寻找位置，减小搜索范围；2.直接根据alias找到库提供的文件位置)。
vue-cli配置文件中提示也有提到这一点，就是下面这段代码
resolve: {
//自动扩展文件后缀名，意味着我们require模块可以省略不写后缀名
extensions: ['.js', '.vue', '.json'],
//模块别名定义，方便后续直接引用别名，无须多写长长的地址
alias: {
'vue$': 'vue/dist/vue.esm.js',//就是这行代码，提供你直接引用文件
'@': resolve('src'),
}
},然后我将其他所有地方关于vue的引用都替换成了vue$之后，比如
// import 'vue'; import 'vue/dist/vue.esm.js';
时间竟然到了12s，也是把我吓了一跳。。。
然后我就把jquery，axios，vuex等等全部给替换掉了。。。大概优化到了9s左右，美滋滋，O(∩_∩)O~~
4.webpack3升级
本来是没第四点，刚刚看到公众号推出来一篇文章讲到升级到webpack3的一些新优点，比如Scope Hoisting(webpack2升级到webpack3基本上没有太大问题)。通过添加一个新的插件
// 2017-08-13配合最新升级的webpack3提供的新功能，可以使压缩的代码更小，运行更快 ... plugin : [ new webpack.optimize.ModuleConcatenationPlugin(), ]
不过在添加这行代码之后，构建时间并没有太大变化，不过运行效率没试过，不知道新的效果怎么样
好了基本上感觉就是以上这些效果对项目的优化最大，虽然没有到网上说的那种只要3~4秒时间那么变态，不过感觉基本8,9秒的时间也可以了。
相信看了本文案例你已经掌握了方法，更多精彩请关注php中文网其它相关文章！
推荐阅读：
The above is the detailed content of How to optimize webpack configuration. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
