webpack优化实践(遇到很奇葩的问题)

1、先上打包前后的优化效果图

2、优化背景

• webpack 的构建过程太花时间
• webpack 打包的结果体积太大
• 作者的项目是webpack 2的老项目（项目已上线很久，不太敢突然的升级webpack版本，以防有意想不到的问题）

3、优化操作

1. 用include或exclude来避免不必要的转义

module: {
    rules: [{
        test: /\.js$/,
        use: {
             loader: 'babel-loader',
        },
        // 规避了对庞大的 node_modules 文件夹或者 bower_components 文件夹的处理
        exclude: /(node_modules|bower_components)/,
        include: resolve('source')
    }]
}
复制代码

2. 开启缓存将转译结果缓存至文件系统

module: {
    rules: [{
        test: /\.js$/,
        use: {
            // 开启缓存
            loader: 'babel-loader?cacheDirectory=true'
        },
        exclude: /(node_modules|bower_components)/,
        include: resolve('source')
    }]
}
复制代码

3. DllPlugin/DLLReferencePlugin优化处理

处理第三方库有多种方式，externals、CommonsChunkPlugin、splitChunks、DllPlugin/DLLReferencePlugin 。我们先说说各种的优劣势

3.1 externals

防止将某些 import 的包(package)打包到 bundle 中，而是在运行时(runtime)再去从外部获取这些扩展依赖(external dependencies)。

<script src="https://unpkg.com/element-ui@2.0.8/lib/index.js"></script>

module.exports= {
    externals: {
        ElementUi: 'ELEMENT' // 主要element-ui保留出来的全局变量是ELEMENT
    }
}

import ElementUi from 'ElementUi';
复制代码

• 优点：操作比较简单，支持多种设置方式，也可以自定义行为。
• 缺点：操作不是很灵活，需要设置多步，并且会出现意想不到的情况。下面我会介绍到。

3.2 CommonsChunkPlugin

通过将公共模块拆出来，最终合成的文件能够在最开始的时候加载一次，便存到缓存中供后续使用。这个带来速度上的提升，因为浏览器会迅速将公共的代码从缓存中取出来， 而不是每次访问一个新页面时，再去加载一个更大的文件。（但是新的webpack中已经被移除，使用的是SplitChunksPlugin）

new webpack.optimize.CommonsChunlPlugin({
      name: string, // or
      names: string[],
      // 这是 common chunk 的名称。已经存在的 chunk 可以通过传入一个已存在的 chunk 名称而被选择。
      // 如果一个字符串数组被传入，这相当于插件针对每个 chunk 名被多次调用
      // 如果该选项被忽略，同时 `options.async` 或者 `options.children` 被设置，所有的 chunk 都会被使用，
      // 否则 `options.filename` 会用于作为 chunk 名。
      // When using `options.async` to create common chunks from other async chunks you must specify an entry-point
      // chunk name here instead of omitting the `option.name`.

      filename: string,
      // common chunk 的文件名模板。可以包含与 `output.filename` 相同的占位符。
      // 如果被忽略，原本的文件名不会被修改(通常是 `output.filename` 或者 `output.chunkFilename`)。
      // This option is not permitted if you're using `options.async` as well, see below for more details.

      minChunks: number|Infinity|function(module, count) -> boolean,
      // 在传入  公共chunk(commons chunk) 之前所需要包含的最少数量的 chunks 。
      // 数量必须大于等于2，或者少于等于 chunks的数量
      // 传入 `Infinity` 会马上生成 公共chunk，但里面没有模块。
      // 你可以传入一个 `function` ，以添加定制的逻辑（默认是 chunk 的数量）

      chunks: string[],
      // 通过 chunk name 去选择 chunks 的来源。chunk 必须是  公共chunk 的子模块。
      // 如果被忽略，所有的，所有的 入口chunk (entry chunk) 都会被选择。

      children: boolean,
      // 如果设置为 `true`，所有公共 chunk 的子模块都会被选择

      deepChildren: boolean,
      // 如果设置为 `true`，所有公共 chunk 的后代模块都会被选择

      async: boolean|string,
      // 如果设置为 `true`，一个异步的  公共chunk 会作为 `options.name` 的子模块，和 `options.chunks` 的兄弟模块被创建。
      // 它会与 `options.chunks` 并行被加载。
      // Instead of using `option.filename`, it is possible to change the name of the output file by providing
      // the desired string here instead of `true`.

      minSize: number,
      // 在 公共chunk 被创建立之前，所有 公共模块 (common module) 的最少大小。
});
复制代码

```javascript 

+   优点：最终合成的文件能够在最开始的时候加载一次，便存到缓存中供后续使用。这个带来速度上的提升。
+   缺点：每次构建时都会重新构建一次 vendor。

#### 3.3 splitChunks

webpack4中支持了零配置的特性，同时对块打包也做了优化，CommonsChunkPlugin已经被移除了，现在是使用optimization.splitChunks代替。

// webpack.config.js
splitChunks: {
chunks: “async”,
minSize: 30000,
minChunks: 1,
maxAsyncRequests: 5,
maxInitialRequests: 3,
automaticNameDelimiter: ‘~’,
name: true,
cacheGroups: {
vendors: {
test: /[\/]node_modules[\/]/,
priority: -10
},
default: {
minChunks: 2,
priority: -20,
reuseExistingChunk: true
}
}
}
复制代码

+   优点：使用SplitChunksPlugin是Webpack 4的默认行为，可能你设置一下chunks: 'all'就足够了，打包速度更快了。
+   缺点：SplitChunksPlugin是Webpack 4的特性，Webpack 4之前不能操作，比如我当前优化项目，webpack 2。

#### 3.4 DllPlugin/DLLReferencePlugin

DllPlugin:是基于 Windows 动态链接库（dll）的思想被创作出来的。这个插件会把第三方库单独打包到一个文件中，这个文件就是一个单纯的依赖库。这个依赖库不会跟着你的业务代码一起被 重新打包，只有当依赖自身发生版本变化时才会重新打包。

DLLReferencePlugin:是基于 Windows 动态链接库（dll）的思想被创作出来的。这个插件会把第三方库单独打包到一个文件中，这个文件就是一个单纯的依赖库。这个依赖库不会跟着你的业务代码。

一起被重新打包，只有当依赖自身发生版本变化时才会重新打包。配置步骤如下：

1.  新增一个配置文件webpack.dll.config.js

const path = require(‘path’);
const webpack = require(‘webpack’);
const CleanWebpackPlugin = require(‘clean-webpack-plugin’);
module.exports = {
entry: {
// 依赖的库数组
vendor: [
‘vue/dist/vue.esm.js’,
‘axios’,
// ‘element-ui’,
‘vue-router’,
‘vuex’,
‘v-viewer’,
‘vue-photo-preview’,
‘mockjs’
]
},
output: {
path: path.join(__dirname, ‘htdocs/dist’),
filename: ‘[name].js’,
library: ‘[name][hash]’,
},
plugins: [
new CleanWebpackPlugin([‘htdocs/dist/vendor-manifest.json’, ‘htdocs/dist/vendor.js’]),
new webpack.DllPlugin({
// DllPlugin的name属性需要和libary保持一致
name: ‘[name][hash]’,
path: path.join(__dirname, ‘htdocs/dist’, ‘[name]-manifest.json’),
// context需要和webpack.config.js保持一致
context: __dirname,
}),
],
}
复制代码

2.  配置package.json命令，npm run dll 这个命令就会生成两个文件，一个是vendor-manifest.json，一个是vendor.js。 vendor.js 不必解释，是我们第三方库打包的结果。这个多出来的 vendor-manifest.json，则用于描述每个第三方库对应的具体路径下。

/ package.json
“scripts”: {
“dll”: “webpack -p –progress –config ./webpack.dll.config.js”
},
复制代码

3.  配置webpack.config.js

module.exports = {
plugins: [
new webpack.DllReferencePlugin({
context: __dirname,
// manifest就是我们第一步中打包出来的json文件
manifest: require(‘./htdocs/dist/vendor-manifest.json’),
})
]
}
复制代码

4.  引入vendor.js，引入vendor.js有两种方式

+   第一种：直接在index.html。，这种方式简单粗暴，针对没有vendor.js没有hash值的，完全ok，但是如果你打包的vendor.js有hash，每次重新 npm run dll之后如果生成了新的hash，就要手动改这个路径了。

+   第二种：add-asset-html-webpack-plugin，该插件会将给定的JS或CSS文件添加到Webpack知道的文件中，并将其放入html-webpack-plugin注入到生成的html 的资产列表中。将插件添加 到您的配置中。（但是需要注意的是此插件需要html-webpack-plugin@^2.10.0。在webpack 4+之后，需要先注册AddAssetHtmlPlugin后才 使用内部使用的钩子，而先前版本的webpack对此 并不关心。HtmlWebpackPluginhtml-webpack-plugin-before-html-generation。）


但是我在操作的时候遇到一个很奇葩的坑，element-ui被dllPlugins之后，el-table不生效，是的不生效，页面也么有报错，样式都还存在，但是就是页面展示不出来table。

我看到element-ui的issues上也有人遇到这样的情况，但是现在还没有一个解决方案，很难受。

![](https://static.javascriptc.com/frontend/webpack/20200408/webpack-14641844f84641844f.webp)

如果不能dll elemenet-ui，打包出来的index文件，还是很大的，怎么办。

![](https://static.javascriptc.com/frontend/webpack/20200408/webpack-190c4a2f7890c4a2f7.webp)

所以我想到了一个办法就是，利用externals来处理element-ui（操作步骤如上），index有80%的大小是element-ui打包之后占据的。但是externals来处理却发现了另外一个问题。index.js打包的文件是小了很多 但是，有一个相应的js文件的大小反而变的很大，这样操作得不偿失。

![](https://static.javascriptc.com/frontend/webpack/20200408/webpack-169723d7f869723d7f.webp)

> 网上有很多解决办法，但是都没有根治我这个问题，最后的解决方案是，单独的使用table，项目重写table。这样的方法也有一个弊端，就是当前只是发现了table不能正常使用，但是如果还有其他 组件不行，也需要重写，这样的成本就很好了。所以，最后项目选择是不打包element-ui（无奈之举）。期待这个问题被解决。

### 4\. happypack-将laoder转换为多线程

webpack 是单线程的，就算此刻存在多个任务，你也只能排队一个接一个地等待处理。这是 webpack 的缺点，好在我们的 CPU 是多核的，Happypack 会充分释放 CPU 在多核并发方面的优势， 帮我们把任务分解给多个子进程去并发执行，大大提升打包效率。

HappyPack 的使用方法也非常简单，只需要我们把对 loader 的配置转移到 HappyPack 中去就好，我们可以手动告诉 HappyPack 我们需要多少个并发的进程：

const HappyPack = require(“happypack”);
// 手动创建进程池
const happyThreadPool = HappyPack.ThreadPool({ size: os.cpus().length });
module.exports = {
plugins: [
new HappyPack({
// 这个HappyPack的“名字”就叫做happyBabel，和楼上的查询参数遥相呼应
id: ‘happyBabel’,
// 指定进程池
threadPool: happyThreadPool,
// 输出日志
verbose: true,
loaders: [‘babel-loader?cacheDirectory’]
}),
]
};
复制代码

### 5\. webpack-parallel-uglify-plugin替换uglifyjs-webpack-plugin

这个插件可以帮助具有许多入口点的项目加速构建。随Webpack提供的uglifyjs插件在每个输出文件上按顺序运行。这个插件与每个可用CPU的一个线程并行运行uglify。这可能会导致显著减少构 建时间，因为最小化是CPU密集型的。简单点来说就是顺序运行改为并行，所以大大提升了构建速度。

// const UglifyJsPlugin = require(‘uglifyjs-webpack-plugin’);
const ParallelUglifyPlugin = require(‘webpack-parallel-uglify-plugin’);
module.exports = {
plugins: [
new ParallelUglifyPlugin({
cacheDir: ‘cache_dir’,//用作缓存的可选绝对路径。如果未提供，则不使用缓存。
sourceMap: config.build.productionSourceMap, //可选布尔值。是否为压缩后的代码生成对应的Source Map(浏览器可以在调试代码时定位到源码位置了),这会减慢编译速度。默认为false
uglifyJS: {
output: {
comments: false,//是否保留代码中的注释，默认为保留
},
warnings: true,//是否在UglifyJS删除没有用到的代码时输出警告信息，默认为false
compress: {
drop_console: true,//是否删除代码中所有的console语句，默认为false
collapse_vars: true,//是否内嵌虽然已经定义了，但是只用到一次的变量， 默认值false
reduce_vars: true,//是否提取出现了多次但是没有定义成变量去引用的静态值，默认为false
}
},
})
]
};
复制代码
“`

6. 路由按需加载

作者优化这个项目之前，开发人员也是分组打包，但是是一个路由打包一个js文件，导致最后的结果就是，生产了60+的js文件，在进行批量发布时，哪速度叫一个感人，作者进行了一个简单的操作优化， 就是根据名称分组打包，最后打包下来只有10+的js，并且我发现，60+文件打包的大小比10+文件的总体大小要大一些。哈哈哈，无意间发现的。

7. 多使用函数式编程

这个优化其实就是一个日常需要注意的问题，但是能间接的提升webpack的打包效率、打包大小的优化。

• 为什么？ 因为在webpack 2开始，是集成了tree-shaking。在Vue的3.0版本，有一个重大的改变就是Vue采用了函数式编程。 函数式更方便tree-shaking（删除无用的方法，例如：100个方法，只使用了1个方法，打包的时候的时候只打包一个方法，删除没有使用的方法），在Vue2.0暴露出去的是一个类， 不利于tree-shaking。在Vue3.0中，使用函数式，全部暴露的是函数，使用哪个函数就是import哪个函数，更方便tree-shaking。减少了代码体积。在简单项目中Vue的打包体积可以降低到10KB左右。

所以我们在日常的操作中多使用函数式编程，来提升webpack的打包效率和打包大小。

4、遗留问题

element-ui被dllPlugins之后，el-table不生效。求大神解决。项目依赖版本如下：

作者：蜗牛的北极星之旅
链接：https://juejin.im/post/5e69ae4b51882549422eed42