文章目录

  • 构建性能
    • 减少模块解析
    • 优化loader性能
    • 限制loader的应用范围
    • 缓存loader结果
    • 开启多线程打包
    • 热替换 (Hot Module Replacement)
  • 传输性能
    • 分包
      • 手动分包
      • 自动分包
    • 单模块体积压缩
      • 代码压缩
      • tree shaking
    • 懒加载
    • gzip
    • 辅助工具
  • 运行性能

关于webpack的性能优化，主要体现在三个方面：

  1. 构建性能：是指在开发阶段的构建性能。当构建性能越高，开发效率越高。
  2. 传输性能：在这方面重点考虑网络中的总传输量、JS文件数量以及浏览器缓存。
  3. 运行性能：主要是指JS代码在浏览器端运行的速度。

构建性能

减少模块解析

模块解析包括：AST抽象语法树分析、依赖分析、模板语法替换

对某个模块不进行解析，可以缩短构建时间

如果某个模块不做解析，该模块经过loader处理侯的代码就是最终代码。

如果没有loader对该模块进行处理，该模块的源码就是最终打包结果的代码。

对于模块中没有其他依赖模块，则不需要解析，可以通过配置module.noParse进行处理：

    module.exports = {
        mode: "development",
        module: {
            noParse: /JQuery/
        }
    }

优化loader性能

限制loader的应用范围

针对一些第三方库，不使用loader进行处理。例如babel-loader，转换一些本身就是用ES5语法书写的第三方库，反而会浪费构建时间。
因此通过module.rules.exclude或module.rules.include，排除或仅包含需要应用loader的场景。

    module.exports = {
        module: {
            rules: [
                {
                    test: /\.js$/,
                    exclude: /node_modules/,
                    //或
                    // include: /src/,
                    use: "babel-loader"
                }
            ]
        }
    }

缓存loader结果

如果某个文件内容不变，经过相同的loader解析后，解析后的结果也不变，所以我们可以把loader的解析结果保存下来，让后续的解析直接用缓存的结果，具体实现如下：

    module.exports = {
      module: {
        rules: [
          {
            test: /\.js$/,
            use: [{
                loader: "cache-loader",
                options:{
                    cacheDirectory: "./cache"
                }
            }, ...loaders]
          },
        ],
      },
    };

cache-loader的原理是，在执行loader之前，如果发现有缓存文件，则直接在loader.pitch函数里return源代码。

那么问题来了，loader明明不是从后往前执行的吗？那为什么cache-loader还可以拿到loader的缓存结果？

其实每个loader的运行过程中，还包括一个过程，即pitch

    function loader(source){
      return `new source`
    }
    loader.pitch = function(filePath){
      // 可返回可不返回
      // 如果返回，返回源代码
    }
    module.exports = loader;

第一次打包时，会先把filepath交给loader1.pitch执行, 检查是否有缓存结果，若无缓存，往后执行。调用loader2.pitch，检查是否有缓存，若无缓冲，往后执行，依次类推…直到最后结束了再调用loader，当调用cache-loader时，就会返回loader处理的结果并缓存。
当第二次打包时（流程同上），若发现有缓存，则直接返回缓存结果，不会继续往后走了，示例图如下：

webpack之常见性能优化

pitch的好处，可以根据是否有返回，来控制下一步到哪。

对于babel-loader，使用它本身的配置也是可以缓存的。

开启多线程打包

通过thread-loader会开启一个线程池，它会把后续的loader放到线程池的线程中运行，以提高构建效率。

    module.exports = {
        module: {
            rules: [{
                test: /\.js$/,
                use: [
                    "thread-loader",
                    "babel-loader"
                ]
            }]
        }
    };

放到线程池的loader的缺点：

  • 无法使用 webpack api 生成文件。
  • 无法使用自定义的 plugin api。
  • 无法访问 webpack options。

thread-loader可以通过测试决定放置的位置。

由于开启和管理线程需要消耗时间，所以在小项目使用会增加构建时间。

热替换 (Hot Module Replacement)

其实，热更新是不能降低构建时间（可能还会稍微增加），因为它发生代码运行期间，但它可以降低代码改动到效果显现的时间。

    //配置文件
    module.exports = {
        devServer: {
            open: true,
            hot: true  //开启HMR
        },
        plugins: [
            new HTMLWebpackPlugin({
                template: "./public/index.html"
            })
        ]
    }
    //index.js
    if(module.hot){ // 是否开启热更新
        module.hot.accept() // 接收热更新
    }

默认情况下，webpack-dev-server不管是否开启了热更新，当重新打包后，都会调用location.reload刷新页面
但如果运行module.hot.accept()，将改变这一行为，
module.hot.accept()的作用是让webpack-dev-server通过socket管道，把服务器更新的内容发送到浏览器，然后，将结果交给插件HotModuleReplacementPlugin注入的代码执行插件HotModuleReplacementPlugin会根据覆盖原始代码，然后让代码重新执行。

对于样式热替换，可使用style-loader。

    module.exports = {
        devServer: {
            open: true,
            hot: true  //开启HMR
        },
        module: {
            rules: [{
                test: /\.css$/,
                use: ["style-loader", "css-loader"]
            }]
        },
        plugins: [
            new HTMLWebpackPlugin({
                template: "./public/index.html"
            })
        ]
    }

为什么不使用mini-css-extract-plugin插件?

因为热更新发生时，HotModuleReplacementPlugin只会简单的重新运行模块代码。因此style-loader的代码一运行，就会重新设置style元素中的样式，而mini-css-extract-plugin生成文件是在构建期间，运行期间无法改动文件。

整个原理流程：

当开启热更新后，Webpack 会轮询问有没有哪些模块发生变化，如果文件内容发生改变，会异步下载更新的代码，向服务器发送请求。下载完毕后，服务器就会主动发送信息给浏览器告知有文件内容发生改变，浏览器发送请求给服务器请求发送修改后的资源文件，服务器接收到请求后把修改的资源文件发送给浏览器，浏览器把接收到的结果交给HotModuleReplacementPlugin，HotModuleReplacementPlugin再覆盖原始代码，再重新执行代码。

传输性能

分包

webpack默认情况下是不会分包的，它会把所有依赖文件合并到一个bundle中。而分包的时机是，当公共模块体积较大 或 有较少的变动，特别是在多页面打包的情况下，会存在多个chunk引入公共模块导致冗余代码的情况，占用打包体积。

分包的目的是在不影响源代码编写的情况下，减少公共代码，降低总体积（特别是一些大型的第三方库）和充分利用浏览器缓存。并非所有的情况都适合分包，需要视具体情况而定。

手动分包

总体思路：

  1. 先单独的打包公共模块，并利用DllPlugin生成资源清单。
  2. 手动引入公共模块，重新设置clean-webpack-plugin，然后使用DllReferencePlugin控制打包结果。

具体打包过程如下：

  1. 开启output.library暴露公共模块
  2. 用DllPlugin创建资源清单
  3. 用DllReferencePlugin使用资源清单
// webpack.dll.config.js
    const webpack = require('webpack');
    module.exports = {
        mode: "production",
            entry: {
                jquery: ["jquery"],
                lodash: ["lodash"]
            },
        output: {
            filename: "dll/[name].js",
            library: "[name]",
            //libraryTarget: "var" //暴露方式
        },
        plugins: [
            new webpack.DllPlugin({
                path: path.resolve(__dirname, "dll", "[name].manifest.json"), //资源清单的保存位置
                name: "[name]"//资源清单中，暴露的变量名
            })
        ]
    };
 //webpack.config.js
 module.exports = {
    plugins:[
        //指定资源清单，在打包时对照资源清单，当发现该模块是资源清单里的资源时不进行打包处理。
        new webpack.DllReferencePlugin({
            manifest: require("./dll/jquery.manifest.json")
        }),
        new webpack.DllReferencePlugin({
            manifest: require("./dll/lodash.manifest.json")
        })
    ]
};

引用：https://webpack.docschina.org/plugins/dll-plugin#dllplugin

自动分包

原理：

  1. 检查每个chunk编译的结果
  2. 根据分包策略，找到那些满足策略的模块
  3. 根据分包策略，生成新的chunk打包这些模块（代码有所变化）
  4. 把打包出去的模块从原始包中移除，并修正原始包代码

在代码层面，有以下变动

  1. 分包的代码中，加入一个全局变量，类型为数组，其中包含公共模块的代码
  2. 原始包的代码中，使用数组中的公共代码

webpack提供了optimization配置项，其中splitChunks是分包策略的配置。

实际上，webpack在内部是使用SplitChunksPlugin进行分包的，分包时，webpack开启了一个新的chunk，对分离的模块进行打包。打包结果中，公共的部分被提取出来形成了一个单独的文件，它是新chunk的产物

过去有一个库CommonsChunkPlugin也可以实现分包，不过由于该库某些地方并不完善，到了webpack4之后，已被SplitChunksPlugin取代。

一般分包是在生产环境下进行的。

分包策略有其默认的配置，只需小小改动即可应用大部分分包场景。

  1. chunks：用于配置需要应用分包策略的chunk。一般只需要配置为 all 即可

    • all: 对于所有的chunk都要应用分包策略
    • async：【默认】仅针对异步chunk应用分包策略
    • initial：仅针对普通chunk应用分包策略

  2. maxSize：可以控制包的最大字节数。

    如果某个包（包括分出来的包）超过了该值，则webpack会尽可能的将其分离成多个包。
    分包的基础单位是模块，如果一个完整的模块超过了该体积，它是无法做到再切割的，因此，尽管使用了这个配置，完全有可能某个包还是会超过这个体积

全局策略：

    module.exports = {
        mode: "production",
        entry: {},
        output: {},
        optimization: {
            splitChunks: {
                // 分包策略
                chunks: "all",
                maxSize: 60000,
                // 分包策略的其他配置
                automaticNameDelimiter: ".", // 新chunk名称的分隔符，默认值~
                minChunks: 1, // 一个模块被多少个chunk使用时，才会进行分包，默认值1
                minSize: 30000, // 当分包达到多少字节后才允许被真正的拆分，默认值30000
            },
        },
        plugins: [],
    }

缓存组策略：
每个缓存组提供一套独有的策略，webpack按照缓存组的优先级依次处理每个缓存组，被缓存组处理过的分包不需要再次分包。

默认情况下，webpack提供了两个缓存组：

    module.exports = {
      optimization:{
        splitChunks: {
          //全局配置
          cacheGroups: {
            // 属性名是缓存组名称，会影响到分包的chunk名
            // 属性值是缓存组的配置，缓存组继承所有的全局配置，也有自己特殊的配置
            vendors: { 
              test: /[\\/]node_modules[\\/]/, // 当匹配到相应模块时，将这些模块进行单独打包
              priority: -10 // 缓存组优先级，优先级越高，该策略越先进行处理，默认值为0
            },
            default: {
              minChunks: 2,  // 覆盖全局配置，将最小chunk引用数改为2
              priority: -20, // 优先级
              reuseExistingChunk: true // 重用已经被分离出去的chunk
            }
          }
        }
      }
    }

单模块体积压缩

代码压缩

代码压缩除了减少代码体积，还可以破坏代码的可读性，提升破解成本。

Terser是一个新起的代码压缩工具，支持ES6+语法。webpack会内置Terser，当启用生产环境后即可用其进行代码压缩。

Terser官网：https://terser.org/

如果想更改、添加压缩工具，又或者是想对Terser进行配置，使用下面的webpack配置即可：

    module.exports = {
        optimization: {
            minimize: true, // 是否要启用压缩，默认情况下，生产环境会自动开启
            minimizer: [
                // 压缩时使用的插件，可以有多个
                new TerserPlugin(), // js压缩插件
                new OptimizeCSSAssetsPlugin() // css压缩插件
            ],
        }
    }

terser、webpack、rollup.js都能够识别/*#__PURE__ */注释标记，/*#__PURE__* /的作用就是告诉打包工具该函数的调用不会产生副作用。

tree shaking

tree shaking可以移除模块之间的无效代码

如果运行环境是生产环境，tree shaking自动开启。

在编写代码时，由于tree shaking需要满足一定的代码规范，所以应该尽量注意规范。例如：

    //使用
    export xxx; //导出
    import {xxx} from "xxx"; // 导入
    //不使用
    export default {xxx}; //导出
    import xxx from "xxx"; // 导入

当webpack依赖分析完毕后，webpack会根据每个模块每个导出是否被使用，标记其他导出为dead code，然后交给代码压缩工具处理，代码压缩工具最终移除掉那些dead code代码。

commonjs很难做到tree shaking，所以主流的库为了做tree shaking，都会发布其es6版本，比如lodash-es。

webpack在tree shaking的使用，有一个原则：一定要保证代码正确运行

在满足该原则的基础上，再来决定如何tree shaking

因此，当webpack无法确定某个模块是否有副作用时，它往往将其视为有副作用

因此，某些情况可能并不是我们所想要的

//common.js
var n  = Math.random();
//index.js
import "./common.js"

虽然我们根本没用有common.js的导出，但webpack担心common.js有副作用，如果去掉会影响某些功能

如果要解决该问题，就需要标记该文件是没有副作用的

在package.json中加入sideEffects

{
    "sideEffects": false
}

有两种配置方式：

  • false：当前工程中，所有模块都没有副作用。注意，这种写法会影响到某些css文件的导入
  • 数组：设置哪些文件拥有副作用，例如：["!src/common.js"]，表示只要不是src/common.js的文件，都有副作用

这种方式我们一般不处理，通常是一些第三方库在它们自己的package.json中标注

由于webpack无法对css完成tree shaking，所以可以通过正则匹配页面样式有没有引用进行移除样式代码。

可以通过purgecss-webpack-plugin进行处理，该插件对css module无法处理。

懒加载

通过动态导入模块，例如在判断里使用导入语句。
导入语句不能使用commonjs，虽然require支持动态导入，但是它在打包环节也会进入依赖分析。
动态加载可以使用import()，import作为es6的草案，webpack打包发现使用import()的调用，会对其单独打包，打包结果该代码时，浏览器会使用JSOP的方式远程去读取一个js模块，import()返回的是一个promise。

    async function run(){
        if(判断条件){ 
            const { chunk } = await import(/* webpackChunkName:'自定义chunkName' */'xxx.js') 
        } 
    } 
    run();

请求的异步的模块会加入webpackJsonp数组里。

值得注意的是，这样的异步导入是不可以做到tree shaking的，不过可以使用取巧的方法，通过一个媒介引入，打包分析过程既能tree shaking又能异步加载。

    //媒介文件
    export { xxx } from '目标文件' 
    //主文件 
    async function run(){ 
        if(判断条件){ 
            const { chunk } = await import( '媒介文件') 
        } 
    }
    run()

gzip

gzip是一种压缩文件的算法

gizp工作原理：

浏览器发送请求时，会在请求头中设置Accept-Encoding:gzip,deflate,br。表明浏览器支持gzip。服务器收到浏览器发送的请求之后，判断浏览器是否支持gizp，如果支持gzip，则向浏览器传送压缩过的内容，不支持则向浏览器发送未经压缩的内容。一般情况下，浏览器和服务器都支持gzip，响应头返回包含content-encoding:gzip。浏览器接收到服务器的响应之后判断内容是否被压缩，如果被压缩则解压缩显示页面内容。

对哪些文件压缩，采用哪种压缩算法，这个需要测试权衡，毕竟压缩文件和解压文件都是需要时间的，对于相对大点的文件一般会有收益。

webpack压缩参与的步骤在于将文件预压缩，当请求到来时直接响应已经压缩的文件，而不需要先压缩再响应。

使用compression-webpack-plugin插件对打包结果进行预压缩，可以移除服务器的压缩时间。

    const CmpressionWebpackPlugin = require("compression-webpack-plugin")
    module.exports = {
      plugins: [
        new CmpressionWebpackPlugin({
          // filename: "[file].gzip"
          test: /\.js/, //针对需要预压缩的文件
          minRatio: 0.5 //压缩比率
        })
      ]
    };

以gzip为例，打包之后的文件包含了.js和.js.gz文件。

辅助工具

  1. ESlint：检查JS代码规范

官网：https://eslint.org/

民间中文网：https://eslint.bootcss.com/

  1. bundle-analyzer：生成代码分析报告，帮助提升代码质量和网站性能

运行性能

运行性能是指，JS代码在浏览器端的运行速度，它主要取决于我们书写代码质量的高低。

关于高性能的代码，可以参考常见的设计模式、代码规范、最佳实践等。

声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。