浅谈webpack4.0 性能优化

摘要：中在性能优化所做的努力，也大抵围绕着这两个大方向展开。因此，将依赖模块从业务代码中分离是性能优化重要的一环。大型库是否可以通过定制功能的方式减少体积。这又违背了性能优化的基础。接下来可以抓住一些细节做更细的优化。中，为默认启动这一优化。

前言：在现实项目中，我们可能很少需要从头开始去配置一个webpack 项目，特别是webpack4.0发布以后，零配置启动一个项目成为一种标配。正因为零配置的webpack对项目本身提供的“打包”和“压缩”功能已经做了优化，所以实际应用中，我们可以把精力更多专注在业务层面上，而无需分心于项目构建上的优化。然而从学习者的角度，我们需要了解webpack在项目的构建和打包压缩过程中做了哪些的优化，以及在原有默认配置上，还可以做哪些性能方面上的改进。

       最近在完成vue的单页面应用后萌生了一个想法，抛弃掉vue-cli的构建配置，从零开始进行webpack优化，并将过程中的思路和体会分享在这篇文章中。webpack的初始配置在我之前写的另一篇手把手教你从零认识webpack4.0文章中，以下内容也不对基本的webpack配置做过多阐述。

       对开发者而言，我们希望webpack这个工具可以给我们带来流畅的开发体验。比如，当不断修改代码时，我们希望代码的变更能及时的通知浏览器刷新页面，而不是手动去刷新页面。更进一步的我们希望，代码的修改只会局部更换某个模块，而不是整个页面的刷新。这样可以使我们不需要在等待刷新中浪费很多时间，大大提高了页面的开发效率。

       项目部署上线时，性能优化是我们考虑的重点，有两个方向可以作为核心考虑的点，一个是减少HTTP请求，我们知道在网速相同的条件下，下载一个100KB的图片比下载两个50KB的图片要快，因此，我们要求webpack将多个文件打包成一个或者少量个文件；另一个优化的重点是减少单次请求的时间，也就是尽可能减少请求文件的体积大小。
       webpack中在性能优化所做的努力，也大抵围绕着这两个大方向展开。另外在构建项目中，我们也希望能持续的提高构建效率。

开发环境下，我们依然对代码的体积有一定的要求，更小的体积可以让加载速度更快，开发效率更高，当然配置也相对简单。

// webpack.dev.js 开发环境webpack配置
module.exports = {
    devServer: {
        contentBase: path.join(__dirname, "dist"),
        port: 9000,
        compress: true, // 代码压缩
      },
}

开发过程中，我们希望修改代码的过程中，页面能实时且不需要手动的刷新。因此使用HRM， HMR 既避免了频繁手动刷新页面，也减少了页面刷新时的等待，大幅度提高了开发效率。

// webpack.dev.js
module.exports = {
  devServer: {
    compress: true,
    hot: true // 开启配置
  },
  plugins: [
    new webpack.NamedModulesPlugin(),
    new webpack.HotModuleReplacementPlugin(),
  ],
}

webpack 在构建中提供了不少于7种的sourcemap模式，其中eval模式虽然可以提高构建效率，但是构建后的脚本较大，因此生产上并不适用。而source-map 模式可以通过生成的 .map 文件来追踪脚本文件的 具体位置，进而缩小脚本文件的体积，这是生产模式的首选，并且在生产中，我们需要隐藏具体的脚本信息，因此可以使用 cheap 和module 模式来达到目的。
综上，在生产的webpack devtool选项中，我们使用 cheap-module-source-map的配置

// webpack.pro.js 生产webpack配置脚本
module.exports = {
  mode: "production",
  devtool: "cheap-module-source-map",  
}

以单入口文件而论，通常我们会将页面的所有静态资源都打包成一个JS 文件，这已经实现了1.2 中的优化部分，将代码合并成一个静态资源，减少了HTTP 请求。

分离前

但是接下来，我们需要将css代码独立开来，为什么呢？最主要的一点是我们希望更好的利用浏览器的缓存，当多带带修改了样式时，独立的css文件可以不需要应用去加载整个的脚本文件，提高效率。并且，当遇到多页面的应用时，可以多带带将一些公共部分的样式抽离开来，加载一个页面后，接下来的页面同样可以利用缓存来减少请求。

webpack4.0 中提供了抽离css文件的插件，mini-css-extract-plugin,只需要简单的配置便可以将css文件分离开来

const MiniCssExtractPlugin = require("mini-css-extract-plugin")

module.exports = {
    ···
    plugins: [
        new MiniCssExtractPlugin({
            filename: "[name].[contenthash].css",
            chunkFilename: "[name].[contenthash].css"
        })
    ],
    module: {
        rules: {
            test: /.(css|scss)$/,
            use: [process.env.NODE_ENV == "production" ? MiniCssExtractPlugin.loader : "style-loader", {
              loader: "css-loader",
              options: {
                sourceMap: true
              },
            }, "sass-loader"]
        }
    }
    ···
}

分离后

要想优化构建后的体积，不断减少静态资源文件的大小，我们希望webpack帮助我们尽可能压缩文件的体积。对于js 脚本文件而言，webpack4.0 在mode 为‘production’时，默认会启动代码的压缩。除此之外，我们需要手动对html和css 进行压缩。
       针对html 的压缩，只需要对html-webpack-plugin进行相关配置。

// webpack.base.js 

module.exports = {
    plugins: [
        new HtmlWebpackPlugin({
          title: "minHTML",
          filename: "index.html",
          template: path.resolve(__dirname, "../index.html"),
          minify: { // 压缩 HTML 的配置
            collapseWhitespace: true,
            removeComments: true,
            useShortDoctype: true
          }
        }),
    ]
}

       针对css 的压缩， webpack4.0 使用optimize-css-assets-webpack-plugin来压缩多带带的css 文件。

const OptimizeCSSAssetsPlugin = require("optimize-css-assets-webpack-plugin");

module.exports = {
    plugins: [
        new OptimizeCSSAssetsPlugin()
    ],
}

对比之下，我们可以看到明显的效果，关于压缩css 更多的配置可以参考optimize-css-assets-webpack-plugin

处理完前端的三大块js,html,css后， 接下来优化能想到的是处理图片。前面提到，提升性能的一个重要的条件是降低http请求数，而应用中经常会有大大小小的图片需要处理，对应用中的小图标来说，css sprite 是首选，将各种图标集合成一张大的图片可以很好的减少网络请求数。而对于需要独立开的图片，且大小在合理范围内时，我们可以将图片转换成 base64位编码，内嵌到css 中，同样可以减少请求。

3.4.1 base64 转换

处理图片资源时，webpack 提供了 file-loader 和url-loader 两个loaders供选择，file-loader 和url-loader 的作用，可以用来解析项目中图片文件的url引入问题。两者的区别在于，url-loader 可以将小于指定字节的文件转为DataURL, 大于指定字节 的依旧会使用file-loader 进行解析

// webpack.base.js
module.exports = {
    module: {
        rules: [{
            test: /.(png|jpe?g|gif|svg|ttf|woff2|woff)(?.*)?$/,
            use: [{
              loader: "url-loader",
              options: {
                limit: 10000, // 限制大小
              }
            }, 
        ]
  },
}

3.4.2 压缩图片

处理完雪碧图和小图片的base64转换后，对于大图片来说，webpack还可以做到对图片进行压缩，推荐使用image-webpack-loader,插件提供了多种形式的压缩，详细可以参考官网文档

// webpack.base.js
module.exports = {
    module: {
        rules: [
            {
              loader: "image-webpack-loader",
              options: {
                optipng: { // 使用 imagemin-optipng 压缩 png，enable: false 为关闭
                  enabled: true,
                },
                pngquant: { // 使用 imagemin-pngquant 压缩 png
                  quality: "65-90",
                  speed: 4
                },
              }
            }
        ]
    }
}

效果对比如下：

一个中大型应用中，第三方的依赖，庞大得可怕，占据了打包后文件的一半以上。然而，这些依赖模块又是很少变更的资源，和css 代码分离的逻辑相似，分离第三方依赖库，可以更好的利用浏览器缓存，提升应用性能。因此，将依赖模块从业务代码中分离是性能优化重要的一环。
webpack4.0 中，依赖库的分离只需要通过 optimization.splitChunks 进行配置即可。

// webpack.pro.js
module.exports = {
    optimization: {
       splitChunks: {
          cacheGroups: {
            vendor: {
              chunks: "initial",
              test: path.resolve(__dirname, "../node_modules"),
              name: "vendor", // 使用 vendor 入口作为公共部分
              enforce: true,
            },
          },
        },
      },
}

公共库分离后的结果

正如前面所讲，在优化分析中，实际影响体积最大的是 node_modules 的第三方库，这一部分的优化可以大大的减少打包后的体积。这里我们使用最新的webpack-bundle-analyzer插件来分析打包好后的模块，它可以将打包后的内容束展示位方便交互的直观树状图，通过它，可以知道项目大致有哪些模块组成，哪个模块占据的体积较大，是否是可替代的。

我们大致可以从几个方向考虑

1.判断依赖是否不可或缺，依赖在项目中使用率是否过低。在项目中，可能针对某个运算，某个功能，我们使用了一个庞大的库，这个库在体积上的占比较大，而功能使用却较少。这个时候我们可以寻找体积更小，且功能满足的替换库，或者手动实现某些依赖的功能来替换他。

2.大型库是否可以通过定制功能的方式减少体积。明显的一个例子是 echart， echart完全版的依赖压缩后也有几百k 之多，这显示是难以接受的。现实项目中，我们可能只需要少量或者部分的echart 功能，这时我们可以通过制定图表的形式，下载图表用到的功能，达到体积最优化。

3.某些不可优化的大型库是否可以通过外部引用的方式减少文件体积。例如像bootstrap，vue这类无法优化的第三方库，通过免费开源的cdn服务不但可以减少文件体积，还可以提高网站的加载速度，也是个优化性能的方法

前面提到依赖分析的方向中，如果大型库不可或缺，而且使用率也不算低的时候，我们可以通过按需加载的形式。这种方式实际上是先把你的代码在一些逻辑断点处分离开，然后在一些代码块中完成某些操作后，立即引用或即将引用另外一些新的代码块。这样加快了应用的初始加载速度，减轻了它的总体体积，因为某些代码块可能永远不会被加载。

webpack中利用require.ensure()实现按需加载，在不使用按需加载的情况下，首屏加载时会把所有的脚本同时加载出来，这往往会拖累首屏显示时间，带来不好的用户体验。例子来说。当项目需要使用大型的图表类库，而首页并不需要时，按需加载往往比同时加载在用户体验上好好得多。

当不需要按需加载的时候，我们的代码可能是这样的：

import test from "./components/test.vue"
import test2 from "./components/test2.vue"

开启按需加载时，我们的代码修改为：

const test = r => require.ensure([], () => r(require("./components/test.vue")), "chunk1")
const test2 = r => require.ensure([], () => r(require("./components/test2.vue")), "chunk2")

webpack 配置修改为

output: {
    ···
    chunkFilename: "[name].[hash].js"
}

这时编译出来的文件会从原来的一个，变成了多个小文件。每个路由加载时会去加载不同的资源。特别在首屏的资源加载上进一步优化了应用的体验。

尽管如此，实际中我们需要根据项目的需求来衡量按需加载的可用性，尽管在首屏优化上取得较大的提升，但按需加载毕竟会将大的文件拆分成多个小文件，增加了http 的请求数。这又违背了性能优化的基础。所以实际中需要取舍，更需要权衡。

代码体积优化到这一步，基本可以优化的地方已经优化完毕了。接下来可以抓住一些细节做更细的优化。比如可以删除项目中上下文都未被引用的代码。这就是所谓的 Tree shaking 优化。webpack 4.0中，mode 为production 默认启动这一优化。但是，如果在项目中使用到babel的 话，需要把babel解析语法的功能关掉。只需要

// .babelrc

{
  "presets": [["env", { "modules": false }]]
}

说完如何减少项目构建后的大小后，接下来简单的谈一下如何提高构建的速度。实际上webpack的 构建速度，只需要简单的修改配置便能大幅提高速度。常见的设置如下。

4.1.1 限定加载器作用范围

由于babel-loader需要将语法进行转换，所耗费的时间较长，所以第一步需要限定babel-loader 作用的范围，让babel-loader 的搜索和转换准确的定位到指定模块。大幅提高构建速度。
例如：

// webpack.base.js
module.exports = {
    module:{
        rules: [
            {
                test: /.js$/,
                include: [resolve("src")],// 限定范围
                use: {
                  loader: "babel-loader",
                },
            },]
    }
}

4.1.2 缓存加载器执行结果

正因为babel-loader在解析转换上耗时太长，所以我们希望能缓存每次执行的结果。webpack的loader中刚好有 cacheDirectory 的选项，默认为false 开启后将使用缓存的执行结果，打包速度明显提升。

// webpack.base.js
module.exports = {
    module: {
        rules: [
            {
            test: /.js$/,
            include: [resolve("src")],
            use: {
              loader: "babel-loader?cacheDirectory",
            },
        },]
    }
}

webpack 的resolve 做相关的配置后，也可以让项目的构建速度加快。具体看下文的配置：

当项目中出现 import "react" 既不是绝对路径也不是相对路径时，指定好搜索的路径，可以不用过多的查询

尽可能少的使用 resolve.alias 来设置路径别名，因为会影响到tree shaking 的优化

后缀自动补全尽可能的少。减少路径查询的工作

当使用的第三方库过大，并且不包含import require define 的调用。可以使用noParse让库不被loaders 解析

// webpack.base.js
module.exports = {
    resolve: {
      modules: [
        path.resolve(__dirname, "node_modules"),
      ],

      extensions: [".js"], 
    
      // 避免新增默认文件，编码时使用详细的文件路径，代码会更容易解读，也有益于提高构建速度
      mainFiles: ["index"],
    }，
    module: {
        noParse: function(content){
            return /jquery/.test(content)
        }
    }
}

webpack性能优化的瓶颈还是集中在构建时间和构建体积上，作为构建工具业界霸主，webpack一直不停的优化构建打包流程。通过对旧有项目的优化也可以对webpack这个工具以及性能优化的知识有更深的了解。

转载请注明出处 https://blog.csdn.net/yuanyan...