企业级项目：webpack中的性能优化

程序员文章站 2022-07-01 19:19:34

...

webpack性能优化概述

很多很多人都认为性能是一个项目必不可少的，我总结了有关webpack构建项目中的性能优化的几个方面。在了解性能优化之前，最好对webpack编译原理有所了解，方便更深入的学习。
可以参考：大神眼中的webpack构建工具：对编译原理的分析

本文中性能优化目录：

构建性能：是指在开发阶段的构建性能，而不是生产环境的构建性能，尽可能提高开发效率
- 减少模块解析：
- 优化loader性能
- 热替换
传输性能：服务端的JS传输给客户端的时间。总代码量越少，时间越少。文件数量越少，http请求次数越少。
- 分包
  - 手动分包
  - 自动分包
- 体积优化
  - 代码压缩
  - tree shaking
- 懒加载
- gzip
运行性能：在浏览器端的运行速度。
- 运行性能主要在书写代码中体现

一、构建性能

1、减少模块解析

企业级项目：webpack中的性能优化
模块解析包括：抽象语法树分析、依赖分析、模块语法替换。如果一个模块不做模块解析，那么经过loaders处理后的代码就是最后的源码。但是模块解析又是必须要做的步骤，那么如何减少模块解析？嘿嘿。如果一个模块中没有其他依赖就可以不对其进行模块解析，其实，减少模块解析主要是针对一些已经打包好的第三方库，比如jquery等。配置一个模块不进行解析很简单，只要在module中配置noParse。一个正则表达式。

module.exports = {
    mode: "development",
    devtool: "source-map",
    module: {
        rules:[],
        noParse: /jquery/
    }
}

2、优化loader性能

（1）减少loader应用范围

优化loader的性能，其实就是进一步限制loader的应用范围，对于某些库，不需要使用loader，比如说babel-loader，babel-loader是将某些ES2015+转换为浏览器识别的语法。但是某些库，本来就没有使用这么高版本的语法，使用loader处理完全是浪费时间，所以不需要对其进行loader处理了呀。比如loadsh库。我们可以通过配置，让其跳过loader处理。

通过module.rule.exclude或module.rule.include，排除或仅包含需要应用loader的场景

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

当然，第三方大部分库都已经对其进行了babel处理，如果暴力一点，甚至可以排除掉node_modules目录中的模块，或仅转换src目录的模块。但是要慎重，排除之前要去官网看看是否已经处理过了。

module.exports = {
    module: {
        rules: [
            {
                test: /\.js$/,
                exclude: /node_modules/,
                //也可以用 include: /src/,效果相同
                use: "babel-loader"
            }
        ]
    }
}

（2）缓存loader的结果

如果某个文件内容不变，经过相同的loader解析后，解析后的结果也不变，所以我们可以将loader的解析结果保存下来，让后续的解析直接使用缓存的结果，当然这种方式会增加第一次构建时间

cache-loader可以实现这样的功能，要将cache-loader放在最前面，虽然放在最前面，但是他可以决定让后续loader是否运行。具体配置看官方文档！

module.exports = {
  module: {
    rules: [
      {
        test: /\.js$/,
        use: [
            {
                loader: "cache-loader",
                options:{
                  cacheDirectory: "./cache" //缓存的目录
                }
          	}, ...loaders] //其余的loaders
      },
    ],
  },
};

实际上，loader的运行过程中，还包含一个过程，即pitch

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-l6TffEJ7-1584435464160)(F:\博客\前端工程化\assets\pitch-loader运行过程.png)]

（3）为loader开启多线程

如果loader进行处理的过程是一个异步操作的话，可以大大减少处理时间，thread-loader会开启一个线程池，它会把后续的loader放到线程池的线程中运行，以提高构建效率。因为后续的loader是放入新的线程池中，就无法使用webpack api、自定义的plugin api，也无法访问的webpack options。具体把thread-loader放在什么位置，要根据项目视情况而定，可以傻瓜式测试。但要注意的是，开启和管理新的线程也是需要时间的。

module.exports = {
  mode: "development",
  devtool: "source-map",
  module: {
    rules: [
      {
        test: /\.js$/,
        use: [
          "file-loader",
          "thread-loader", //将thread-loader和babel-loader放入新的线程中
          "babel-loader"
        ]
      }
    ]
  }
};

3、热替换 HMR

我们在使webpack-dev-server开发服务器时，他会事时的监控代码变动，不需要重新带包，但是webpack-dev-server发现代码变动的时候，浏览器会刷新，重新请求所有资源。这显然不是我们开发最理想的结果，我们更希望，当我们更改一部分代码的时候，浏览器不刷新，只是局部进行替换。热替换就是实习了局部替换。要注意热替换不会讲题构建的性能，但是它可以降低代码变动到效果呈现的时间。

使用webpack-dev-server的流程：
企业级项目：webpack中的性能优化

使用热替换的流程：
企业级项目：webpack中的性能优化

使用热替换

更改配置：

module.exports = {
  devServer:{
    hot:true // 开启热替换
  },
  plugins:[ 
    new webpack.HotModuleReplacementPlugin() //使用插件
  ]
}

更改代码：随便一个文件写入以下代码，只要保证运行即可

// index.js
if(module.hot){ // 是否开启了热更新
  module.hot.accept() // 接受热更新
}

热替换原理

当在配置文件中开启了热替换后，webpack-dev-server会向打包结果中注入module.hot属性，所以在上述文件中添加的module.hot代码。默认情况下，webpack-dev-server不管是否开启了热更新，当重新打包后，都会调用location.reload刷新页面，但是如果运行了module.hot.accept()，就不会再调用loaction.reload()来刷新页面，而是使用websocket的方式，module.hot.accept()会让服务器更新的内容通过websocket传送给浏览器，仅仅是传输修改的部分。然后将结果交给插件HotModuleReplacementPlugin注入的代码执行，插件HotModuleReplacementPlugin会根据覆盖原始代码，然后让代码重新执行。

比如我在这里修改了一个js文件的模块导出，当监控到代码发生变化以后，websocket向客户端发出了两个服务，第一个是热替换的哈希值，不解释。

企业级项目：webpack中的性能优化

第二个就是需要热替换的代码，当接收到这个这段代码的时候，HotModuleReplacementPlugin插件就会根据key值"./src/a.js"来找到模块的位置，将模块的value重新覆盖。

企业级项目：webpack中的性能优化
module.hot.accept()的作用是让webpack-dev-server通过socket管道，把服务器更新的内容发送到浏览器
简单来说，热替换就是开启热替换的webpack-dev-server开发服务器监控到代码变化，通过websocket从服务的向客户端发送变化的内容，客户端接受到变化的内容后替换掉原内容。

样式热替换

对于样式也是可以使用热替换的，需要使用style-loader，因为热替换发生时HotModuleReplacementPlugin只会简单的重新运行模块代码。因此style-loader的代码一运行，就会重新设置style元素中的样式。而mini-css-extract-plugin，由于它生成文件是在构建期间，运行期间并会也无法改动文件，因此它对于热替换是无效的。

二、传输性能

1、手动分包

手动分包的总体思路是先单独打包公共模块，公共模块会被打包成一个动态链接库(ddl)，并且形成一个资源清单。然后再根据入口模块进行正常的打包过程。

企业级项目：webpack中的性能优化
当正常打包时，如果发现模块中使用了资源清单中描述的模块，如下

//源码，入口文件index.js
import $ from "jquery"
import _ from "lodash"
_.isArray($(".red"));

由于资源清单中包含jquery和lodash两个模块，因此打包结果不会出现jquery和lodash的源代码，而是通过导出一个模块的方式，如下

(function(modules){
  //...
})({
  // index.js文件的打包结果并没有变化
  "./src/index.js":
  function(module, exports, __webpack_require__){
    var $ = __webpack_require__("./node_modules/jquery/index.js")
    var _ = __webpack_require__("./node_modules/lodash/index.js")
    _.isArray($(".red"));
  },
  // 由于资源清单中存在，jquery的代码并不会出现在这里
  "./node_modules/jquery/index.js":
  function(module, exports, __webpack_require__){
    module.exports = jquery;
  },
  // 由于资源清单中存在，lodash的代码并不会出现在这里
  "./node_modules/lodash/index.js":
  function(module, exports, __webpack_require__){
    module.exports = lodash;
  }
})

这样一来，重复代码就会减少，也就减少了传输时的体积。

（1）打包公共模块

打包公共模块是一个独立的打包过程，所以我们通常会重建一个配置文件webpack.dll.config.js，需要两个过程，首先打包公共模块，暴露变量名，然后用DllPlugin插件生成资源清单

const path = require("path")
const webpack = require("webpack")
module.exports = {
  mode: "production",
  entry: {//打包公共模块
    jquery: ["jquery"],
    lodash: ["lodash"]
  },
  output: {
    filename: "dll/[name].js",
    library: "[name]"//
  },
  plugins: [//生成资源清单
    new webpack.DllPlugin({
      path: path.resolve(__dirname, "dll", "[name].manifest.json"), //资源清单的保存位置
      name: "[name]"//资源清单中，暴露的变量名
    })
  ]
};

运行后，即可完成公共模块打包

npx webpack --config webpack.dll.config.js

（2）使用公共模块

在页面中手动引入公共模块

<script src="./dll/jquery.js"></script>
<script src="./dll/lodash.js"></script>

为了避免把公共模块清除，需要重新设置clean-webpack-plugin，如果没有使用你该插件则忽略

new CleanWebpackPlugin({
  // 要清除的文件或目录
  // 排除掉dll目录本身和它里面的文件
  cleanOnceBeforeBuildPatterns: ["**/*", '!dll', '!dll/*']
})

目录和文件的匹配规则使用的是globbing patterns

使用DllReferencePlugin，告诉webpack资源清单的位置，如果遇到导出模块已经在资源清单中，则不需要再进行打包。

module.exports = {
  plugins:[
    new webpack.DllReferencePlugin({
      manifest: require("./dll/jquery.manifest.json")
    }),
    new webpack.DllReferencePlugin({
      manifest: require("./dll/lodash.manifest.json")
    })
  ]
}

简单来说，手动打包首先要开启output.library暴露公共模块，使用webpack.DllPlugin插件生成资源清单（可以不使用，自己写），然后在页面中引入资源清单中的依赖，最后用DllReferencePlugin插件使用资源清单。

在手动打包的过程中，我们需要注意，资源清单是不参与运行的，所以不能把资源清单放在打包目录中。

手动打包优点：

极大提升自身模块的打包速度
极大的缩小了自身文件体积
有利于浏览器缓存第三方库的公共代码

缺点：

使用非常繁琐
如果第三方库中包含重复代码，则效果不太理想

2、自动分包

自动包区别于手动分包的是不需要确定具体为那个模块分包，而是从一个宏观的角度来控制分包，那么要控制分包，就需要有一个合理的分包策略。webpack4已经放弃了原来用CommonsChunkPlugin实现分包，而是在内部使用SplitChunksPlugin进行分包。

分包流程：分包时，webpack根据分包策略，实现具体的分包，它会开启一个新的chunk，对分离的模块进行打包处理。公共代码会生成新chunk即common，最后打包成budle_common.js 如图所示：
企业级项目：webpack中的性能优化

自动分包原理：自动分包会检查每个chunk编译的结果，根据分包策略，找到那些满足策略的模块，并生成新的chunk打包这些模块，再将打包出去的模块从原来的包中移除，并修改原来包的代码

（1）分包策略的基本配置

webpack提供了optimization配置项，用于配置一些优化信息，其中splitChunks是分包策略的配置，其中有以下常用配置

chunks：该配置项用于配置需要应用分包策略的chunk，有以下三个值，默认时async
- all: 对于所有的chunk都要应用分包策略，一般来说使用这个值
- async：仅针对异步chunk应用分包策略
- initial：仅针对普通chunk应用分包策略
maxSize：如果一个要被分出来的包超过了该值，webpack就会尽可能的将其分成多个包。注意：分包的基础单位是模块，如果一个完整的模块超过了该体积，它是无法做到再切割的，因此，尽管使用了这个配置，完全有可能某个包还是会超过这个体积。通常不使用
automaticNameDelimiter：新chunk名称的分隔符，默认值~
minChunks：一个模块至少被多少个chunk使用时，才会进行分包，默认值1
minSize：当分包达到多少字节后才允许被真正的拆分，默认值30000

module.exports = {
  optimization: {
    splitChunks: {
      //分包配置
      chunks: "all",
      //maxSize: 60000
      automaticNameDelimiter: ".",
      minChunks: 2,
      minSize: 30000
    }
  }
}

（2）缓存组

实际上，分包策略是基于缓存组的。每个缓存组提供一套独有的策略，webpack按照缓存组的优先级依次处理每个缓存组，被缓存组处理过的分包不需要再次分包。默认情况下，webpack提供了两个缓存组，很多时候，缓存组对于我们来说没什么意义，因为默认的缓存组就已经够用了。

webpack默认缓存组

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

通过缓存组对公共样式分离：webpack.config.js

const { CleanWebpackPlugin } = require("clean-webpack-plugin");
const MiniCssExtractPlugin = require("mini-css-extract-plugin");
const HtmlWebpackPlugin = require("html-webpack-plugin")
module.exports = {
  optimization: {
    splitChunks: {
      chunks: "all",
      cacheGroups: {
        styles: {
          test: /\.css$/, // 匹配样式模块
          minSize: 30000, 
          minChunks: 2
        }
      }
    }
  },
  module: {
    rules: [{ test: /\.css$/, use: [MiniCssExtractPlugin.loader, "css-loader"] }]
  },
  plugins: [
    new CleanWebpackPlugin(),
    new HtmlWebpackPlugin({
      template: "./public/index.html",
      chunks: ["index"]
    }),
    new MiniCssExtractPlugin({
      filename: "[name].[hash:5].css",
      // chunkFilename是配置来自于分割chunk的文件名
      chunkFilename: "common.[hash:5].css" 
    })
  ]
}

3、代码压缩

为生产环境进行代码压缩，减少代码体积是增加传输性能必不可少的环节，进行代码压缩同时也可以破坏代码可读性，提升**成本，目前流行的代码压缩工具主要有UglifyJs和Terser

UglifyJs是一个传统的代码压缩工具，已存在多年，曾经是前端应用的必备工具，但由于它不支持ES6语法，所以目前的流行度已有所下降。

Terser是一个新起的代码压缩工具，支持ES6+语法，因此被很多构建工具内置使用。

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

webpack已经内置了Terser，所以我们在启用生产环境后即可用其进行代码压缩。

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

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

4、tree shaking

代码压缩可以移除模块内部的无效代码，而tree shaking可以移除模块之间的无效代码。比如说

// myMath.js
export function add(a, b){
  console.log("add")
  return a+b;
}

export function sub(a, b){
  console.log("sub")
  return a-b;
}

这个工具模块有两个导出方法，但是整个项目只使用了add，如果在打包的时候两个方法都打包的话无疑会增加无效代码量，tree shaking的作用就是移除无效的代码块。webpack2开始就支持了tree shaking。只要是生产环境，tree shaking自动开启

tree shaking工作原理：webpack会从入口模块出发寻找依赖关系，当解析一个模块时，webpack会根据ES6的模块导入语句来判断，该模块依赖了另一个模块的哪个导出。依赖分析完毕后，webpack会根据每个模块每个导出是否被使用，标记未使用的导出为dead code，然后交给代码压缩工具处理。代码压缩工具最终移除掉那些dead code代码

在具体分析依赖时，webpack坚持的原则是：保证代码正常运行，然后再尽量tree shaking。

我们在书写导入导出时，尽量使用以下方式：

使用export xxx导出，而不使用export default {xxx}导出
使用import {xxx} from "xxx"导入，而不使用import xxx from "xxx"导入

所以，如果你依赖的是一个导出的对象，由于JS语言的动态特性，以及webpack还不够智能，为了保证代码正常运行，它不会移除对象中的任何信息。

ES6的模块导入语句：使用ES6的模块导入语句，有利于更好的分析依赖，是因为ES6模块有以下特点：

导入导出语句只能是顶层语句
import的模块名只能是字符串常量
import绑定的变量是不可变的

使用第三方库tree shaking注意：

某些第三方库可能使用的是commonjs的方式导出，比如lodash又或者没有提供普通的ES6方式导出。对于这些库，tree shaking是无法发挥作用的。但好在很多流行的库都发布了它的ES6版本，比如lodash-es。我们在使用loadsh的时候可以使用lodash-es

副作用函数（side effect）：函数运行过程中，可能会对外部环境造成影响的功能。如果函数中包含以下代码，该函数叫做副作用函数：异步代码、localStorage、对外部数据的修改

纯函数（pure function）：如果一个函数没有副作用，同时，函数的返回结果仅依赖参数，则该函数叫做

webpack坚持的原则是：保证代码正常运行，然后再尽量tree shaking。因此当webpack无法确定某个模块是否有副作用时，它往往将其视为有副作用。当我们知道某个导出没有副作用，但是webpack担心common.js有副作用，如果去掉会影响某些功能，这时候我们就需要标记该文件是没有副作用的。当然，第三方插件中，一般都已经标记过了，我们无需自己添加。

在package.json中加入sideEffects

{
    "sideEffects": false
    //"sideEffects": ["!src/common.js"]
}

5、懒加载

懒加载就是动态加载，按需加载，当我们需要的时候再加载。使用import()语法。import()会返回一个promise。

if(Math.random()<0.5){
	const {add} =await import("./utils.js")
	const result = add(1,3)
}

此时，utils工具类是等到要执行时才会引入，而不会变成顶层语句直接执行。当我们执行到import时才会到服务端请求该模块的js文件，而不是在页面加载的时候就去请求，可以减少首页加载时间过长

6、gzip

gzip是一种压缩文件的算法，当我们js文件过大的时候，就可以使用gzip的方式，对文件进行压缩，配合服务器端进行使用。

具体使用参照1：
webpack-dev-server开发服务器和 webpack中常用plugin和loader一文中的compression-webpack-plugin插件
具体使用参照2：
webpack+nginx实现gzip压缩解决vue首屏加载过慢

企业级项目：webpack中的性能优化

webpack性能优化概述

一、构建性能

1、减少模块解析

2、优化loader性能

（1）减少loader应用范围

（2）缓存loader的结果

（3）为loader开启多线程

3、热替换 HMR

使用热替换

热替换原理

样式热替换

二、传输性能

1、手动分包

（1）打包公共模块

（2）使用公共模块

2、自动分包

（1）分包策略的基本配置

（2）缓存组

3、代码压缩

4、tree shaking

5、懒加载

6、gzip

Python中优化NumPy包使用性能的教程

iOS开发中UITableview控件的基本使用及性能优化方法

MySQL中聚合函数count的使用和性能优化技巧

Oracle性能优化——SQL基线（SQLbaseline）的载入与进化（11g中引入的基线）

MySQL性能优化：MySQL中的隐式转换造成的索引失效

Web 性能优化：使用 Webpack 分离数据的正确方法

性能优化篇之Webpack构建速度优化的建议

性能优化篇之Webpack构建代码质量压缩的建议

oracle性能优化（项目中的一个sql优化的简单记录）

Python中优化NumPy包使用性能的教程

企业级项目：webpack中的性能优化

webpack性能优化概述

一、构建性能

1、减少模块解析

2、优化loader性能

（1）减少loader应用范围

（2）缓存loader的结果

（3）为loader开启多线程

3、热替换 HMR

使用热替换

热替换原理

样式热替换

二、传输性能

1、手动分包

（1）打包公共模块

（2）使用公共模块

2、自动分包

（1）分包策略的基本配置

（2）缓存组

3、代码压缩

4、tree shaking

5、懒加载

6、gzip

Python中优化NumPy包使用性能的教程

iOS开发中UITableview控件的基本使用及性能优化方法

MySQL中聚合函数count的使用和性能优化技巧

Oracle性能优化——SQL基线（SQLbaseline）的载入与进化（11g中引入的基线）

MySQL性能优化：MySQL中的隐式转换造成的索引失效

Web 性能优化： 使用 Webpack 分离数据的正确方法

性能优化篇之Webpack构建速度优化的建议

性能优化篇之Webpack构建代码质量压缩的建议

oracle性能优化（项目中的一个sql优化的简单记录）

Python中优化NumPy包使用性能的教程

Web 性能优化：使用 Webpack 分离数据的正确方法