Skip to main content

构建优化策略

前端构建优化通常围绕两个核心指标展开：构建速度（开发体验）和产物性能（包体积与运行速度）。

一、提升构建速度 (Build Speed)​

当项目变得庞大时，Webpack 的构建时间可能会成倍增加，以下是常见的优化手段：

  1. 缩小构建目标范围
    • 优化 Loader 配置中的 test、include、exclude，只转译必要的文件。
    • 合理配置 resolve.alias 和 resolve.extensions，减少 Webpack 查找文件的路径和后缀尝试。
  2. 利用缓存 (Caching)
    • Webpack 5：直接开启内置的持久化缓存 cache: { type: 'filesystem' }，大幅提升二次构建速度。
    • Webpack 4：使用 cache-loader 或 hard-source-webpack-plugin。
  3. 多进程/多线程构建
    • 使用 thread-loader 将耗时的 Loader（如 babel-loader）分配到 worker 池中并行处理。
    • 使用 terser-webpack-plugin 开启并行压缩（Webpack 5 默认已开启）。
  4. 替换更高效的转译工具
    • 代码转译（Babel/TS）属于 CPU 密集型任务。可以使用基于 Go 的 esbuild-loader 或基于 Rust 的 swc-loader 替代传统的 babel-loader，能获得数量级的速度提升。
  5. 减少不必要的插件
    • 比如在开发环境中关闭不必要的代码压缩和 Terser 插件，或者关闭 progressPlugin。

二、优化产物性能 (Bundle Size & Runtime)​

1. 代码分割与分包 (Code Splitting & SplitChunks) - 面试重点​

在默认情况下，Webpack 会将所有业务代码和第三方依赖打包到一个庞大的 bundle.js 中。这会导致首屏加载极慢，且一旦业务代码修改，整个 Bundle 的缓存就会失效。

代码分包的核心策略：

  1. 路由懒加载：使用动态 import() 语法按需加载首屏不需要的组件。
  2. 提取第三方库 (Vendor)：将 node_modules 下的资源单独打包（如 React、Lodash）。这些库极少变动，可以充分利用浏览器的长期缓存。
  3. 提取公共业务模块 (Common)：将多个页面（入口）引用的公共业务组件或 Utils 提取为一个 Chunk，避免重复打包。
  4. 分离 Runtime 代码：配置 optimization.runtimeChunk: 'single'，将 Webpack 的运行时核心代码单独拆分，防止因模块 ID 变化导致的主 Bundle 缓存失效。

SplitChunksPlugin 示例配置：

module.exports = {
  optimization: {
    runtimeChunk: "single", // 提取 runtime 代码
    splitChunks: {
      chunks: "all", // 对同步和异步 chunk 均进行优化
      cacheGroups: {
        vendor: {
          test: /[\\/]node_modules[\\/]/,
          name: "vendors",
          chunks: "all",
        },
        common: {
          minChunks: 2, // 至少被引用 2 次才提取
          name: "commons",
          chunks: "all",
          priority: -10, // 优先级低于 vendor
        },
      },
    },
  },
};

2. 移除无用代码​

  • Tree Shaking：移除未使用的 JS 代码（依赖 ES Modules 静态语法，生产模式默认开启）。
  • 清理无用 CSS：结合 PurgeCSS 移除未使用的样式类。

3. 外部依赖 (Externals)​

将 React、Vue、Echarts 等体积较大的库通过 externals 配置排除在 Bundle 之外，改用 CDN 在 HTML 中通过 <script> 标签引入。这既能大幅减小包体积，又能利用 CDN 节点加速资源下载。

4. 资源压缩​

  • JS 压缩：使用 TerserPlugin。
  • CSS 压缩：使用 CssMinimizerWebpackPlugin。
  • 图片压缩：使用 image-webpack-loader。

5. Source Map 控制​

  • 开发环境：使用 eval-cheap-module-source-map 提升重构建速度。
  • 生产环境：关闭 Source Map，或使用 hidden-source-map（生成但不暴露在产物中，配合 Sentry 等错误上报平台定位问题，防止源码泄露）。

6. 利用浏览器缓存与预加载​

  • 长期缓存：输出文件名使用 [contenthash]，确保只有文件内容改变时 hash 才改变，最大化利用强缓存。
  • 预获取/预加载：配合 HTTP 的 Prefetch / Preload 加载空闲资源（使用 Webpack 魔法注释 /* webpackPrefetch: true */）。

面试高频：Webpack 4 升级到 Webpack 5 为什么有明显性能提升？​

Webpack 5 在性能上（特别是二次构建速度和包体积优化上）带来了质的飞跃，主要归功于以下几个核心优化点：

  1. 内置持久化缓存 (Persistent Caching)
    • Wp4：每次重启开发服务器或重新构建时，都需要重新解析和编译所有模块。要实现缓存必须借助第三方 Loader/Plugin（如 cache-loader、hard-source-webpack-plugin），配置繁琐且容易出 Bug。
    • Wp5：原生支持并默认启用了基于文件系统的持久化缓存（cache: { type: 'filesystem' }）。它能缓存生成的 Webpack 模块和 Chunk，极大地提升了二次构建（Rebuild）和冷启动的速度。
  2. 更优的 Tree Shaking
    • 嵌套 Tree Shaking：Wp5 能够追踪到嵌套模块导出中的依赖关系。如果一个模块导出了另一个模块的部分成员，Wp5 也能准确识别并剔除未使用的深层代码。
    • CommonJS Tree Shaking：Wp4 仅支持 ESM 的 Tree Shaking，而 Wp5 增加了对部分 CommonJS 构造（如 module.exports）的代码消除支持。
  3. 确定的模块/代码块 ID (Deterministic IDs)
    • Wp4：默认使用自增数字作为 Module ID 和 Chunk ID。如果在代码中间新增一个模块，会导致后续所有模块的 ID 改变，进而导致这些文件的 contenthash 改变，使得浏览器长缓存全部失效。
    • Wp5：引入了确定的（Deterministic）ID 算法。它根据模块的相对路径生成简短的 Hash 值。这保证了无论如何增删模块，未改变模块的 ID 始终不变，从而最大化利用浏览器缓存。
  4. 更高级的代码生成 (Advanced Code Generation)
    • Wp5 会生成更符合现代 JavaScript 引擎（如 V8）解析习惯的、更简洁的运行时代码，减少了闭包和不必要的包装函数，进一步减小了产物体积。
  5. 移除 Node.js Polyfill
    • Wp4 默认会为 crypto、buffer、path 等 Node 核心模块注入 Polyfill，导致很多前端根本用不到的代码被打包进去。Wp5 彻底移除了自动 Polyfill 注入机制，强迫开发者按需引入，从而显著减小了默认情况下的包体积。