Webpack 构建优化实战：从 Loader 配置到多进程处理

Webpack 构建优化概述

简介

本文基于《深入浅出webpack》一书，梳理了常用的 Webpack 构建优化方案，旨在通过具体手段提升项目的构建效率。

精确配置 Loader 与模块查找

更精准的 Loader 规则

明确 Loader 的处理范围

核心原则是仅让需要处理的文件进入 Loader 环节，具体配置参考下方代码示例。

  rules: [{
   // 正则尽量准确
   test: /\.js$/,
   // 使用缓存，缓存后在文件未改变时编译会更快(缓存查找原理见补充1)
   use: ['babel-loader?cacheDirectory'],
   // 指定需要处理的目录
   include: path.resolve(__dirname, 'src')
   // 理论上只有include就够了，但是某些情况需要排除文件的时候可以用这个，排除不需要处理文件
   // exclude: []
  }]

更精准的模块查找目录

将模块查找路径设置得尽可能精确。

通常情况下，项目的第三方依赖都位于项目根目录下的 node_modules 中。因此，我们可以显式设置查找目录，从而减少 Node.js 默认的递归查找开销（默认查找机制见补充内容2）。

module.exports = {
  resolve: {
    // 指定当前目录下的node_modules目录
    modules: [path.resolve(__dirname, 'node_modules')]
  }
}

更精准的扩展名解析

在扩展名数组中，数量更多或更常用的文件类型应排在前面。

日常编码中，我们习惯省略文件扩展名直接引用文件名。此时，Webpack 会按照 extensions 配置的顺序进行解析尝试。

module.exports = {
  extensions: ['.js', '.jsx', '.ts', '.tsx'],
}

扩展名解析的默认值配置见下方代码。

extensions: [".js", ".json"]

动态链接库预编译策略

使用动态链接库预编译大型模块

利用动态链接库机制，提前编译体积庞大的第三方模块。

具体原理请参考补充内容3。

新建一个独立的配置文件 webpack_dll.config.js，内容如下所示。

const path = require('path');
const webpack = require('webpack');

// 复用的大模块放在这里，这样每次都不需要重新编译了
const vendors = [
 'react',
 'react-dom',
 'lodash'
];

module.exports = {
 mode: 'development',
 output: {
  path: path.resolve(__dirname, './dist'),
  filename: '[name].js',
  library: '[name]',
 },
 entry: {
  vendors,
 },
 plugins: [
  new webpack.DllPlugin({
   path: path.resolve(__dirname, './dist/manifest.json'),
   name: '[name]',
  }),
 ],
};

执行 webpack --config webpack_dll.config.js 进行首次编译。如果后续依赖版本发生更新，需要重新执行此步骤以生成新的链接库。

随后，在主 Webpack 配置文件中引入生成的 manifest.json 文件，以引用预编译的模块。

 plugins: [
  new webpack.DllReferencePlugin({
   manifest: require('./dist/manifest.json')
  })
 ],

多进程处理与压缩优化

利用多进程处理文件

使用 HappyPack 插件同时处理多个 Loader 编译任务。

为了充分利用多核 CPU 的性能，HappyPack 将构建任务分发给多个子进程并发执行。

const path = require('path');
const HappyPack = require('happypack');
// 共享5个进程池
const happyThreadPool = HappyPack.ThreadPool({ size: 5 });

module.exports = {
 entry: './src/index.js',
 output: {
  filename: 'bundle.js',
  path: path.resolve(__dirname, 'dist'),
 },
 module: {
  // noParse: [/react\.production\.min\.js$/],
  rules: [{
   test: /\.js$/,
   // 和下面插件id一直，happypack才可以找到
   use: ['happypack/loader?id=babel'],
   include: path.resolve(__dirname, 'src')
  }]
 },
 plugins: [
  // 插件可以实例化多个
  new HappyPack({
   // 与上面对应
   id: 'babel',
   // 实际要使用的loader
   loaders: ['babel-loader?cacheDirectory'],
   // 默认开启进程数
   threads: 3,
   // 是否允许happyPack打印日志
   verbose: true,
   // 共享进程数，如果你使用超过一个happyplugin，官方建议共享进程池
   threadPool: happyThreadPool
  })
 ],
};

其工作原理见补充内容4。

多进程压缩文件

使用 ParallelUglifyPlugin 插件实现多进程并行压缩文件。

ParallelUglifyPlugin 基于 UglifyJS 开发，增加了多进程处理能力，从而加快了代码压缩速度。

import ParallelUglifyPlugin from 'webpack-parallel-uglify-plugin';
 
module.exports = {
 plugins: [
  new ParallelUglifyPlugin({
   test,
   include,
   exclude,
   cacheDir,
   workerCount,
   sourceMap,
   uglifyJS: {
   },
   uglifyES: {
   }
  }),
 ],
};

文件监听与其他优化手段

减少监听文件范围

缩小文件监听范围

相关原理见补充内容5。

当使用 Webpack 的 watch 功能进行文件监听时，更优的做法是严格控制监听的目录。例如，通过配置排除 node_modules 目录，可以减少需要循环检查的文件数量，从而显著提高文件变更的检测速度。

module.export = {
  watchOptions: {
    ignored: /node_modules/
  }
}

其他次要优化策略

更精准的 mainFields 配置

该默认值的查找逻辑详见官网文档。

经观察 React 和 Lodash 等库，其 package.json 中通常只定义了一个 main 字段。目前看来，直接使用 ES6 模块打包的方式尚不普遍，因此该配置项在当前阶段的重要性相对较低。

module.exports = {
  resolve: {
    mainFields: ['main']
  }
}

第三方库映射优化

之所以认为其重要性较低，是因为像 React 这样的库直接导出的 index.js 通常会根据运行环境自动判断加载哪份代码。从实际效果看，似乎并不需要通过复杂的循环依赖处理来优化。

通过建立明确的依赖映射，可以直接使用打包后的代码，从而避免 Webpack 进行额外的循环依赖解析。

 resolve: {
  mainFields: ["main"],
  alias: {
   'react': path.resolve(__dirname, './node_modules/react/cjs/react.production.min.js')
  }
 }

不使用 inline 模式的 devServer

相关原理见补充内容6。

默认情况下，应用程序会启用内联模式（inline mode）。这意味着一段用于处理实时重载的脚本会被插入到你的打包文件（bundle）中，并且构建消息会显示在浏览器控制台中。

当使用 inline 模式时，devServer 会向每一个 Chunk 中注入一段重载脚本代码。然而，实际上一个页面只需要注入一次即可。因此，当 Chunk 数量过多时，建议将 inline 设置为 false 以优化性能。

module.export = {
  devServer: {
    inline: false
  }
}

核心机制原理解析

补充说明

补充1：cacheDirectory 原理

当设置 cacheDirectory 时，指定的目录将用于缓存 Loader 的执行结果。在后续的 Webpack 构建中，系统将尝试读取缓存，从而避免每次执行时可能产生的高性能消耗的 Babel 重新编译过程。如果设置为空值（loader: 'babel-loader?cacheDirectory'）或 true（loader: babel-loader?cacheDirectory=true），Loader 将使用默认的缓存目录 node_modules/.cache/babel-loader。如果在任何根目录下都未找到 node_modules 目录，则会降级回退到操作系统默认的临时文件目录。

补充2：Node.js 的默认模块查找方式

• 首先查找当前目录下的 node_modules 目录，看是否有匹配项，如有则命中文件。
• 若当前目录未找到，则寻找父目录下的 node_modules，如有则命中文件。
• 按照此规则一直向父目录搜索，直到到达根目录下的 node_modules 为止。

补充3：动态链接库思想

对于大量项目中可以复用的模块，只需要被编译一次。在后续的构建过程中，包含在动态链接库中的模块将不再重新编译，而是直接复用动态链接库中的代码。（注：如果升级了依赖模块的版本，则需要重新编译动态链接库。）

补充4：HappyPack 原理

Webpack 构建过程中涉及大量的 Loader 转换操作，非常耗时。由于 Node.js 是单线程运行的，为了更好地利用 CPU 的多核能力，可以开启多个进程同时处理文件。在配置文件中，我们将文件交给 happypack-loader 处理，然后由 HappyPack 调度执行具体的处理逻辑（HappyPack 通过 id 确定使用哪个 Loader 进行处理）。

补充5：文件监听原理

Webpack 会从入口文件出发，将所有依赖项放入一个列表中。每次修改文件内容时，系统会遍历该列表中的所有文件，检查文件的编辑时间是否发生变化。如果有变化，则触发重新编译。

补充6：自动刷新原理

• 向待开发的网页中注入代理客户端代码，通过代理客户端去刷新整个页面（这是默认行为）。
• 将待开发的网页放入一个 iframe 中，通过刷新 iframe 来查看刷新效果。

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持本站。