用 Webpack 点燃前端性能：从理论到实战的优化秘籍

1. 理解 Webpack 的性能瓶颈：从“慢”到“快”的第一步

Webpack 的强大之处在于它能把零散的模块化代码整合成高效的输出文件，但如果配置不当，它也可能成为性能的“黑洞”。性能瓶颈通常出现在以下几个环节：

• 打包时间过长：模块数量多、依赖复杂，导致构建过程像蜗牛爬行。

• 输出文件体积过大：冗余代码、未压缩的资源，让用户加载时间飙升。

• 运行时性能低下：不合理的 chunk 分割或加载方式，拖慢页面渲染。

解决这些问题，核心在于“精简”和“提速”。Webpack 提供了丰富的配置选项，但你得知道从哪里下手。我们先从最基础的优化入手——分析构建性能，找到症结所在。

1.1 用 speed-measure-webpack-plugin 揪出耗时元凶

想优化，首先得知道哪里慢。speed-measure-webpack-plugin（简称 SMP）是一个神器，能详细告诉你 Webpack 每个 Loader 和 Plugin 的耗时。安装它就像给你的构建过程装上“计时器”。

npm install speed-measure-webpack-plugin --save-dev

在 webpack.config.js 中引入并使用：

const SpeedMeasurePlugin = require('speed-measure-webpack-plugin');
const smp = new SpeedMeasurePlugin();

module.exports = smp.wrap({
  // 你的 Webpack 配置
  entry: './src/index.js',
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'bundle.js',
  },
  module: {
    rules: [
      {
        test: /\.js$/,
        use: ['babel-loader'],
      },
    ],
  },
});

运行构建后，SMP 会输出一份详细的耗时报告，精确到每个 Loader 和 Plugin。比如，你可能会发现 babel-loader 耗时过长，这时候可以考虑用 cacheDirectory 开启缓存：

{
  test: /\.js$/,
  use: {
    loader: 'babel-loader',
    options: {
      cacheDirectory: true, // 缓存编译结果，提速明显！
    },
  },
}

实战小贴士：如果你的项目用的是 TypeScript，ts-loader 可能是个耗时大户。试试 fork-ts-checker-webpack-plugin，它会把类型检查放到单独的进程，显著减少构建时间。

1.2 用 webpack-bundle-analyzer 看清输出文件

光提速还不够，输出的 bundle 体积也得控制。webpack-bundle-analyzer 能生成一个可视化的依赖图，让你一目了然哪些模块占用了大头。

npm install webpack-bundle-analyzer --save-dev

配置如下：

const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;

module.exports = {
  plugins: [
    new BundleAnalyzerPlugin({
      analyzerMode: 'server', // 启动一个本地服务查看分析结果
      openAnalyzer: true,
    }),
  ],
};

运行后，浏览器会弹出一个交互式图表，展示每个模块的大小和依赖关系。比如，你可能发现某个第三方库（如 moment.js）体积惊人，这时候可以考虑用更轻量的 day.js 替代。

关键点：分析工具是优化的第一步。别急着改配置，先用 SMP 和 Bundle Analyzer 找到“罪魁祸首”，才能对症下药！

2. 代码分割：让你的 Bundle “瘦身”又高效

前端性能的头号杀手是大而全的 bundle 文件。用户加载一个 5MB 的 JS 文件，光是下载就得等上好几秒。Webpack 的代码分割（Code Splitting）能把大文件拆成小块，按需加载，极大提升首屏渲染速度。

2.1 动态导入：按需加载的魔法

Webpack 支持 ES Modules 的动态导入（import()），可以轻松实现按需加载。比如，假设你的项目有个复杂的图表模块，只在用户点击“查看数据”时需要加载：

// src/index.js
document.getElementById('showChart').addEventListener('click', () => {
  import('./chartModule.js').then((module) => {
    module.renderChart();
  });
});

Webpack 会自动把 chartModule.js 打包成一个单独的 chunk，只有当用户点击按钮时才会加载。输出文件名可以自定义：

module.exports = {
  output: {
    filename: '[name].bundle.js',
    chunkFilename: '[name].chunk.js', // 动态加载的 chunk 命名
  },
};

效果：首屏加载的 JS 体积大幅减少，用户体验更流畅！

2.2 SplitChunksPlugin：自动拆分公共代码

Webpack 内置的 SplitChunksPlugin 能自动提取多个入口或动态导入的公共依赖。比如，你的 index.js 和 chartModule.js 都依赖 lodash，可以配置 SplitChunksPlugin 把 lodash 单独打包：

module.exports = {
  optimization: {
    splitChunks: {
      chunks: 'all', // 提取所有类型的 chunk
      cacheGroups: {
        vendors: {
          test: /[\\/]node_modules[\\/]/, // 匹配 node_modules 里的模块
          name: 'vendors',
          chunks: 'all',
        },
      },
    },
  },
};

运行后，lodash 会被打包到 vendors.chunk.js，避免重复加载。注意：合理设置 minSize（默认 30KB），太小的 chunk 反而会增加 HTTP 请求次数。

2.3 实战案例：优化一个电商页面

假设你开发一个电商网站，首页有商品列表、搜索框和推荐模块。推荐模块使用了 swiper 库，体积较大，且只有部分用户会交互。我们可以用动态导入优化：

// src/recommend.js
export async function initRecommend() {
  const { default: Swiper } = await import('swiper');
  // 初始化 Swiper
  new Swiper('.swiper-container', {
    // Swiper 配置
  });
}

在首页中：

// src/index.js
import { initRecommend } from './recommend.js';

if (document.querySelector('.swiper-container')) {
  initRecommend();
}

这样，swiper 只有在页面包含推荐模块时才会加载，首页的初始 bundle 体积减少了至少 200KB（视 swiper 版本而定）。

小技巧：用 IntersectionObserver 检测推荐模块是否进入视口，再触发动态导入，能进一步延迟加载，节省带宽。

3. Tree Shaking：砍掉无用代码的“利斧”

Tree Shaking 是 Webpack 的杀手锏之一，能自动移除未使用的代码，减少 bundle 体积。听起来很酷，但实际效果取决于你的代码结构和配置。

3.1 确保 Tree Shaking 生效

Tree Shaking 依赖 ES Modules 的静态结构，因此你得确保：

1. 使用 ES Modules：避免 CommonJS（require），因为它的动态特性让 Webpack 难以分析。

2. 设置 mode: 'production'：生产模式会自动启用 Tree Shaking。

3. 标记 sideEffects：在 package.json 中声明哪些文件没有副作用。

比如，你的工具函数库 utils.js：

export function add(a, b) {
  return a + b;
}

export function multiply(a, b) {
  return a * b;
}

在 index.js 中只用了 add：

import { add } from './utils.js';
console.log(add(2, 3)); // multiply 会被 Tree Shaking 移除

为了让 Webpack 更高效地识别无副作用代码，在 package.json 中添加：

{
  "sideEffects": false
}

如果某些文件有副作用（比如 CSS 或 Polyfill），可以单独指定：

{
  "sideEffects": ["*.css", "./src/polyfills.js"]
}

3.2 实战：优化第三方库

很多第三方库（如 lodash）不支持 Tree Shaking，因为它们用的是 CommonJS。可以用 lodash-es 替代，它是 ES Modules 版本。假设你只用 debounce：

import { debounce } from 'lodash-es';

const handler = debounce(() => {
  console.log('窗口调整完成');
}, 200);

window.addEventListener('resize', handler);

Webpack 会只打包 debounce 相关的代码，lodash-es 其他模块被自动剔除，bundle 体积减少几十 KB。

注意：Tree Shaking 不是万能的。如果你的代码有复杂的动态导入或副作用，Webpack 可能“不敢”删除代码。可以用 eslint-plugin-tree-shaking 检测潜在问题。

4. 缓存为王：用长效缓存加速二次访问

前端性能不只是首屏加载，二次访问的体验同样重要。Webpack 可以通过合理的文件名和哈希策略，利用浏览器缓存减少重复下载。

4.1 善用 contenthash

Webpack 提供了 [contenthash] 占位符，根据文件内容生成哈希值。只有内容变化时，文件名才会改变，确保未修改的文件能长期缓存。

module.exports = {
  output: {
    filename: '[name].[contenthash].js',
    chunkFilename: '[name].[contenthash].chunk.js',
  },
};

为什么不用 [hash]？ 因为 [hash] 是基于整个构建的哈希，任何文件改动都会让所有文件名变化，缓存全废！而 [contenthash] 只对修改的文件生效。

4.2 配置 runtimeChunk

Webpack 的运行时代码（负责模块加载的逻辑）会嵌入每个 bundle。如果不分离，任何模块变化都会导致 bundle 的 contenthash 失效。配置 runtimeChunk 可以解决这个问题：

module.exports = {
  optimization: {
    runtimeChunk: {
      name: 'runtime',
    },
  },
};

这会生成一个单独的 runtime.[contenthash].js 文件，体积小且很少变化，完美适合长期缓存。

4.3 实战：为 SPA 配置长效缓存

假设你开发一个单页应用（SPA），包含 main.js（主逻辑）、vendors.js（第三方库）和 runtime.js。配置如下：

module.exports = {
  entry: {
    main: './src/index.js',
  },
  output: {
    filename: '[name].[contenthash].js',
    chunkFilename: '[name].[contenthash].chunk.js',
  },
  optimization: {
    runtimeChunk: {
      name: 'runtime',
    },
    splitChunks: {
      cacheGroups: {
        vendors: {
          test: /[\\/]node_modules[\\/]/,
          name: 'vendors',
          chunks: 'all',
        },
      },
    },
  },
};

部署时，配合服务端的缓存头：

location ~* \.(js|css)$ {
  expires 1y;
  add_header Cache-Control "public";
}

效果：第三方库（如 vendors.js）和运行时文件（runtime.js）几乎永不变化，用户只需缓存一次，二次访问只需加载更新的 main.js，速度飞快！

5. 压缩与优化：让 Bundle 再“瘦”一点

大体积的 bundle 是前端性能的头号敌人，哪怕已经做了代码分割和 Tree Shaking，压缩仍然是不可或缺的一环。Webpack 配合强大的压缩工具，能让你的 JS、CSS 和图片资源变得更轻量，加载速度嗖嗖快！

5.1 JS 压缩：Terser 登场

Webpack 5 内置了 TerserWebpackPlugin，它是生产环境下压缩 JS 的标配，能移除空格、注释、未用变量，还能把代码混淆得“面目全非”（当然，只是对人类而言）。默认情况下，mode: 'production' 会自动启用 Terser，但我们可以手动调优：

const TerserPlugin = require('terser-webpack-plugin');

module.exports = {
  mode: 'production',
  optimization: {
    minimize: true,
    minimizer: [
      new TerserPlugin({
        parallel: true, // 启用多线程压缩，超大项目必备
        terserOptions: {
          compress: {
            drop_console: true, // 移除 console.log，生产环境更干净
            pure_funcs: ['console.info', 'console.debug'], // 指定移除的函数
          },
          mangle: true, // 混淆变量名，减小体积
        },
      }),
    ],
  },
};

实战效果：一个 1MB 的 bundle 经过 Terser 压缩，可能缩减到 300KB 左右，配合 Gzip（服务端开启），体积还能再降 50%！

小心踩坑：drop_console 会移除所有 console.log，如果你的项目依赖日志调试，记得在开发环境关闭此选项。可以用 process.env.NODE_ENV 动态控制：

new TerserPlugin({
  terserOptions: {
    compress: {
      drop_console: process.env.NODE_ENV === 'production',
    },
  },
});

5.2 CSS 压缩：用 CssMinimizerPlugin

CSS 文件也得瘦身！css-minimizer-webpack-plugin 是 Webpack 的 CSS 压缩利器，能优化 CSS 代码，移除无用样式和重复规则。搭配 mini-css-extract-plugin（用于提取 CSS 到单独文件），效果更佳。

先安装：

npm install css-minimizer-webpack-plugin mini-css-extract-plugin --save-dev

配置如下：

const MiniCssExtractPlugin = require('mini-css-extract-plugin');
const CssMinimizerPlugin = require('css-minimizer-webpack-plugin');

module.exports = {
  module: {
    rules: [
      {
        test: /\.css$/,
        use: [MiniCssExtractPlugin.loader, 'css-loader'],
      },
    ],
  },
  plugins: [
    new MiniCssExtractPlugin({
      filename: '[name].[contenthash].css',
    }),
  ],
  optimization: {
    minimizer: [
      new CssMinimizerPlugin(), // 自动压缩 CSS
    ],
  },
};

实战案例：假设你的项目有个 200KB 的 CSS 文件，包含大量重复的样式（如 margin: 0px 写成 margin: 0）。压缩后可能缩减到 100KB，再加上 Gzip，实际传输体积可能只有 30KB！

小技巧：如果用的是 PostCSS，可以加个 postcss-preset-env 插件，自动清理过时的 CSS 前缀（如 -webkit-box-shadow），进一步减小体积。

5.3 图片优化：image-minimizer-webpack-plugin

图片往往是前端资源的大头，尤其在电商或内容型网站。image-minimizer-webpack-plugin 能压缩 PNG、JPEG 和 WebP 格式的图片，配合 Webpack 的 asset/resource 模块类型，轻松优化。

安装依赖：

npm install image-minimizer-webpack-plugin imagemin imagemin-webp --save-dev

配置：

const ImageMinimizerPlugin = require('image-minimizer-webpack-plugin');

module.exports = {
  module: {
    rules: [
      {
        test: /\.(png|jpe?g|webp)$/,
        type: 'asset/resource',
      },
    ],
  },
  plugins: [
    new ImageMinimizerPlugin({
      minimizer: {
        implementation: ImageMinimizerPlugin.imageminMinify,
        options: {
          plugins: [
            ['jpegtran', { progressive: true }], // 渐进式 JPEG
            ['optipng', { optimizationLevel: 5 }], // 优化 PNG
            ['webp', { quality: 75 }], // 转为 WebP 格式
          ],
        },
      },
    }),
  ],
};

效果：一张 500KB 的 PNG 可能压缩到 200KB，转换为 WebP 后可能只有 100KB！用户加载速度提升，流量成本也直线下降。

注意：图片压缩会增加构建时间，建议只在生产环境启用，或者用 cache 选项缓存压缩结果：

new ImageMinimizerPlugin({
  cache: true,
});

6. 懒加载与预加载：让用户“感觉”更快

优化前端性能，不仅要减少资源体积，还要聪明地控制加载时机。懒加载（Lazy Loading）和预加载（Preload/Prefetch）是 Webpack 的两大杀招，能让用户“感觉”页面快得飞起。

6.1 懒加载：只加载用户需要的内容

我们已经在代码分割里提到过动态导入（import()），它天然支持懒加载。但如何判断哪些模块适合懒加载？答案是：延迟非关键资源的加载。比如，页面底部的评论模块、弹窗组件，或者只有特定交互才会触发的功能。

实战案例：在一个博客网站中，评论区只有用户滚动到页面底部才需要加载。可以用 IntersectionObserver 结合动态导入：

// src/comments.js
export function initComments() {
  console.log('评论区初始化');
  // 加载评论相关的逻辑
}

// src/index.js
function lazyLoadComments() {
  const commentSection = document.querySelector('#comments');
  const observer = new IntersectionObserver((entries) => {
    if (entries[0].isIntersecting) {
      import('./comments.js').then((module) => {
        module.initComments();
        observer.disconnect(); // 加载后停止观察
      });
    }
  });
  observer.observe(commentSection);
}

lazyLoadComments();

效果：评论模块的 JS（假设 50KB）只有在用户滚动到评论区时才会加载，首屏加载时间减少，带宽更省！

6.2 预加载与预获取：提前准备好资源

懒加载适合非关键资源，但有些模块虽然不是立即需要，却很可能被用户访问（比如点击“下一步”按钮加载的模块）。这时候可以用 Preload（预加载）或 Prefetch（预获取）。

• Preload：告诉浏览器立即加载资源，但优先级低于首屏资源。适合“马上要用”的模块。

• Prefetch：在浏览器空闲时加载资源，适合“可能要用”的模块。

Webpack 支持通过 /* webpackPreload: true */ 或 /* webpackPrefetch: true */ 魔法注释实现：

// src/index.js
document.getElementById('nextPage').addEventListener('click', () => {
  import(/* webpackPreload: true */ './nextPage.js').then((module) => {
    module.renderNextPage();
  });
});

document.getElementById('settings').addEventListener('click', () => {
  import(/* webpackPrefetch: true */ './settings.js').then((module) => {
    module.openSettings();
  });
});

区别：

• nextPage.js 是用户点击“下一页”后必须加载的，Preload 确保它优先加载。

• settings.js 是用户可能访问的设置页面，Prefetch 让浏览器在空闲时偷偷加载。

服务端配合：在 HTML 中添加 <link rel="preload" href="nextPage.chunk.js" as="script"> 或 <link rel="prefetch" href="settings.chunk.js" as="script">，进一步强化效果。

6.3 实战：优化一个图片密集型页面

假设你开发一个图片画廊页面，首屏只显示 5 张图片，其余图片在用户滚动时加载。我们可以用懒加载图片，并预加载即将显示的图片：

// src/gallery.js
export function initGallery() {
  const images = document.querySelectorAll('.gallery img');
  images.forEach((img) => {
    if (img.dataset.src) {
      const observer = new IntersectionObserver((entries) => {
        if (entries[0].isIntersecting) {
          img.src = img.dataset.src; // 懒加载图片
          observer.disconnect();
        }
      });
      observer.observe(img);
    }
  });
}

在 HTML 中，首屏图片用 Preload：

<link rel="preload" href="image1.webp" as="image">
<img src="image1.webp" alt="首屏图片">
<img data-src="image2.webp" alt="懒加载图片">

效果：首屏图片秒加载，后续图片按需加载，页面流畅且节省带宽。

7. 多线程构建：让 Webpack 跑得像超跑

当你的项目模块数量破千、依赖树复杂到像迷宫，Webpack 的构建时间可能长得让人想砸键盘。别急，多线程构建能让你的构建过程快得像坐上了超跑！通过并行处理 Loader 和任务，我们可以大幅缩短构建时间，尤其适合大型项目。

7.1 用 thread-loader 分担重活

thread-loader 能把耗时的 Loader 任务（比如 babel-loader 或 ts-loader）丢到独立的 Worker 线程运行，充分利用多核 CPU。安装它很简单：

npm install thread-loader --save-dev

配置时，把 thread-loader 放在耗时 Loader 之前，比如：

module.exports = {
  module: {
    rules: [
      {
        test: /\.js$/,
        use: [
          'thread-loader', // 放第一个，开启多线程
          {
            loader: 'babel-loader',
            options: {
              cacheDirectory: true, // 结合缓存，效果更佳
            },
          },
        ],
      },
    ],
  },
};

效果：在四核 CPU 上，thread-loader 能将 Babel 的编译时间缩短 30%-50%，具体取决于模块数量和文件大小。

小心踩坑：thread-loader 启动 Worker 线程有一定开销，适合处理大量文件。如果项目较小（比如几十个模块），可能反而变慢。可以用 speed-measure-webpack-plugin 测试效果，决定是否启用。

7.2 parallel-webpack：并行运行多个构建

如果你的项目有多个入口（比如 SPA 和管理后台分开打包），可以用 parallel-webpack 同时运行多个 Webpack 构建任务，进一步压榨 CPU 的潜力。

安装：

npm install parallel-webpack --save-dev

创建一个 parallel.config.js：

module.exports = [
  {
    entry: './src/app.js',
    output: {
      path: path.resolve(__dirname, 'dist/app'),
      filename: 'app.[contenthash].js',
    },
  },
  {
    entry: './src/admin.js',
    output: {
      path: path.resolve(__dirname, 'dist/admin'),
      filename: 'admin.[contenthash].js',
    },
  },
];

运行：

npx parallel-webpack --config parallel.config.js

实战效果：假设单个构建需要 10 秒，两个入口串行构建要 20 秒，用 parallel-webpack 可能缩短到 12 秒，效率提升近 40%！

小技巧：结合 thread-loader，可以在每个构建任务内再并行处理 Loader，效果叠加。但要留意内存占用，超大项目可能需要限制并行任务数：

module.exports = {
  // ... 其他配置
  threadLoader: {
    pool: 2, // 限制最多 2 个 Worker 线程
  },
};

7.3 实战：优化一个多入口项目

假设你开发一个电商平台，有三个入口：home.js（首页）、product.js（商品页）、admin.js（管理后台）。每个入口都有大量 TypeScript 文件，构建慢得像乌龟爬。我们可以用 fork-ts-checker-webpack-plugin（类型检查放到单独进程）和 thread-loader 组合优化：

const ForkTsCheckerWebpackPlugin = require('fork-ts-checker-webpack-plugin');

module.exports = {
  module: {
    rules: [
      {
        test: /\.ts$/,
        use: [
          'thread-loader',
          {
            loader: 'ts-loader',
            options: {
              transpileOnly: true, // 跳过类型检查，交给 fork-ts-checker
            },
          },
        ],
      },
    ],
  },
  plugins: [
    new ForkTsCheckerWebpackPlugin(), // 异步类型检查
  ],
};

效果：类型检查和 TS 编译并行运行，构建时间从 30 秒降到 15 秒，开发体验大幅提升！

注意：多线程优化需要权衡。如果你的机器 CPU 核心数少（比如老旧笔记本），并行任务可能导致系统卡顿。可以用 os.cpus().length 动态设置线程数：

const os = require('os');
module.exports = {
  threadLoader: {
    workers: Math.max(1, os.cpus().length - 1), // 留一个核心给系统
  },
};

8. 模块联邦：微前端与模块共享的未来

随着前端项目规模暴涨，单体应用的打包方式已经捉襟见肘。模块联邦（Module Federation）是 Webpack 5 的明星功能，允许不同项目动态共享模块，堪称微前端的“超级胶水”。它不仅能减少重复代码，还能让多个团队协作更高效。

8.1 模块联邦的核心概念

模块联邦让一个 Webpack 构建（称为主机，Host）可以动态加载另一个构建（称为远程，Remote）的模块。核心配置包括：

• exposes：声明要共享的模块。

• remotes：指定要引用的远程模块。

• shared：定义共享的依赖（如 React、Vue）。

8.2 配置模块联邦：一个简单例子

假设你有两个项目：app1（主机，渲染主页面）和 app2（远程，提供一个按钮组件）。

app2 的配置（远程）：

const { ModuleFederationPlugin } = require('webpack').container;

module.exports = {
  output: {
    publicPath: 'http://localhost:3002/', // 远程模块的访问地址
  },
  plugins: [
    new ModuleFederationPlugin({
      name: 'app2',
      filename: 'remoteEntry.js',
      exposes: {
        './Button': './src/Button.js', // 暴露 Button 组件
      },
      shared: {
        react: { singleton: true }, // 共享 React，避免重复加载
        'react-dom': { singleton: true },
      },
    }),
  ],
};

app1 的配置（主机）：

const { ModuleFederationPlugin } = require('webpack').container;

module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'app1',
      remotes: {
        app2: 'app2@http://localhost:3002/remoteEntry.js', // 引用 app2
      },
      shared: {
        react: { singleton: true },
        'react-dom': { singleton: true },
      },
    }),
  ],
};

在 app1 中使用远程模块：

// src/index.js（app1）
import React from 'react';
import ReactDOM from 'react-dom';

const Button = React.lazy(() => import('app2/Button')); // 动态加载远程 Button

ReactDOM.render(
  <React.Suspense fallback="Loading...">
    <Button />
  </React.Suspense>,
  document.getElementById('root')
);

效果：app1 无需本地包含 Button 组件的代码，直接从 app2 加载，减少了 bundle 体积，还能让 app2 独立开发和部署。

8.3 实战：优化一个微前端项目

假设你开发一个企业级仪表盘，包含 dashboard（主机）、charts（远程图表模块）和 auth（远程认证模块）。我们用模块联邦实现模块共享：

charts 的配置：

module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'charts',
      filename: 'remoteEntry.js',
      exposes: {
        './LineChart': './src/LineChart.js',
        './BarChart': './src/BarChart.js',
      },
      shared: {
        react: { singleton: true, eager: true },
        'react-dom': { singleton: true, eager: true },
        'recharts': { singleton: true }, // 共享图表库
      },
    }),
  ],
};

dashboard 的配置：

module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'dashboard',
      remotes: {
        charts: 'charts@http://localhost:3001/remoteEntry.js',
      },
      shared: {
        react: { singleton: true, eager: true },
        'react-dom': { singleton: true, eager: true },
        'recharts': { singleton: true },
      },
    }),
  ],
};

在 dashboard 中动态加载图表：

import React, { Suspense } from 'react';
const LineChart = React.lazy(() => import('charts/LineChart'));

function Dashboard() {
  return (
    <Suspense fallback={<div>加载图表中...</div>}>
      <LineChart data={mockData} />
    </Suspense>
  );
}

效果：dashboard 的 bundle 不包含 recharts 和图表组件代码，全部从 charts 远程加载。recharts 作为共享依赖，只加载一次，节省了至少 500KB 的体积！

小技巧：用 eager: true 强制共享依赖立即加载，适合核心库（如 React）。对于非核心依赖，可以用 requiredVersion 指定版本，防止版本冲突：

shared: {
  recharts: {
    singleton: true,
    requiredVersion: '^2.0.0',
  },
}

注意：模块联邦需要服务端支持 CORS，或者部署到同一域名下。开发时可以用 webpack-dev-server 的 cors 选项快速测试：

module.exports = {
  devServer: {
    headers: {
      'Access-Control-Allow-Origin': '*',
    },
  },
};

9. 性能监控：让 Webpack 的优化可持续

优化不是一劳永逸的事，项目迭代、依赖更新、需求变更都可能让性能悄悄“翻车”。要想保持前端的丝滑体验，性能监控是你的最佳盟友。Webpack 提供了强大的 stats 数据，结合外部工具如 Lighthouse 和 Chrome DevTools，我们可以持续追踪构建和运行时的性能表现。

9.1 用 Webpack stats 分析构建细节

Webpack 的 stats 输出是一个宝藏，包含了构建过程中的所有细节：模块大小、依赖关系、构建时间等。默认情况下，运行 webpack --json > stats.json 会生成一个 JSON 文件，记录整个构建的信息。

怎么用？ 直接在命令行运行：

npx webpack --json > stats.json

生成的 stats.json 可以用工具可视化，比如 Webpack Visualizer 或 Statoscope。安装 Statoscope：

npm install @statoscope/cli --save-dev

运行分析：

npx statoscope stats.json

Statoscope 会生成一个交互式 HTML 报告，展示模块大小、重复依赖、构建耗时等。比如，你可能发现某个模块被多次打包（重复依赖），可以通过调整 SplitChunksPlugin 解决：

module.exports = {
  optimization: {
    splitChunks: {
      chunks: 'all',
      cacheGroups: {
        commons: {
          name: 'commons',
          minChunks: 2, // 至少被 2 个模块引用的依赖才提取
          priority: -10,
        },
      },
    },
  },
};

实战效果：Statoscope 帮你发现一个 100KB 的重复依赖（比如 lodash 被不同 chunk 重复打包），提取后 bundle 体积减少，加载速度提升！

9.2 结合 Lighthouse 监控运行时性能

Webpack 优化了构建和 bundle，但用户体验还得靠运行时性能。Google 的 Lighthouse 是分析页面性能的神器，能给出首屏加载时间（FCP）、可交互时间（TTI）等指标。运行方式有三种：

• Chrome DevTools：打开浏览器开发者工具，切换到 Lighthouse 面板，点击“Generate report”。

• 命令行：安装 lighthouse CLI：

npm install -g lighthouse
lighthouse http://localhost:3000 --view

• Node API：集成到 CI 流程，自动监控性能。

假设 Lighthouse 报告显示你的页面 FCP（首次内容绘制）超过 3 秒，可能是 bundle 体积过大或关键资源加载慢。可以回过头检查：

• 是否用 Preload 加速关键资源？（见第 6 章）

• 是否有多余的 CSS 阻塞渲染？用 mini-css-extract-plugin 提取 CSS 并压缩。

小技巧：Lighthouse 的“Opportunities”部分会直接建议优化点，比如“Remove unused CSS”或“Defer offscreen images”。对照这些建议调整 Webpack 配置，效果立竿见影！

9.3 自动化性能监控：集成到 CI

为了防止性能退化，建议把性能监控融入 CI 流程。用 webpack-stats-diff 比较两次构建的 bundle 大小变化：

npm install webpack-stats-diff --save-dev

运行对比：

npx webpack-stats-diff stats-old.json stats-new.json

如果新构建的 bundle 体积增加超过 10%，CI 可以报错，提醒开发者检查。比如，你可能发现新引入的 chart.js 导致 bundle 膨胀，可以考虑动态导入：

import(/* webpackChunkName: "chart" */ 'chart.js').then((Chart) => {
  // 初始化图表
});

效果：自动化监控让性能问题无处遁形，团队协作更高效！

注意：监控不是越多越好，重点关注关键指标（如 bundle 体积、FCP、TTI）。过多的检查会拖慢 CI 流程，得不偿失。

10. 综合优化案例：打造一个性能炸裂的电商项目

现在，让我们把前面学到的所有技巧整合起来，优化一个复杂的电商项目！这个项目有以下特点：

• 多页面应用：包含首页、商品详情页、购物车、用户中心。

• 大量依赖：React、Ant Design、Axios、Moment.js 等。

• 复杂交互：图片懒加载、动态加载的推荐模块、实时搜索。

• 性能瓶颈：首屏加载慢（5 秒）、构建时间长（20 秒）、二次访问缓存不佳。

目标：首屏加载时间降到 2 秒以内，构建时间缩短到 10 秒，二次访问接近瞬开。

10.1 项目分析与优化计划

先用 speed-measure-webpack-plugin 和 webpack-bundle-analyzer 分析瓶颈：

const SpeedMeasurePlugin = require('speed-measure-webpack-plugin');
const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;
const smp = new SpeedMeasurePlugin();

module.exports = smp.wrap({
  plugins: [
    new BundleAnalyzerPlugin({
      analyzerMode: 'server',
      openAnalyzer: true,
    }),
  ],
});

分析结果：

• 构建慢：babel-loader 和 ts-loader 耗时占 70%。

• bundle 大：moment.js（300KB）、antd（500KB）全量打包。

• 运行时问题：首屏 CSS 和 JS 阻塞渲染，图片未优化。

优化计划：

1. 加速构建：用 thread-loader 和 fork-ts-checker-webpack-plugin。

2. 瘦身 bundle：动态导入 Ant Design 组件，替换 Moment.js。

3. 优化加载：懒加载图片，预加载关键资源。

4. 长效缓存：用 [contenthash] 和 runtimeChunk。

10.2 优化构建速度

针对 ts-loader 和 babel-loader 的耗时，配置多线程和异步类型检查：

const ForkTsCheckerWebpackPlugin = require('fork-ts-checker-webpack-plugin');

module.exports = {
  module: {
    rules: [
      {
        test: /\.tsx?$/,
        use: [
          'thread-loader',
          {
            loader: 'ts-loader',
            options: {
              transpileOnly: true,
            },
          },
        ],
      },
      {
        test: /\.js$/,
        use: [
          'thread-loader',
          {
            loader: 'babel-loader',
            options: {
              cacheDirectory: true,
            },
          },
        ],
      },
    ],
  },
  plugins: [
    new ForkTsCheckerWebpackPlugin(),
  ],
};

效果：构建时间从 20 秒降到 12 秒！

10.3 瘦身 Bundle：动态导入与 Tree Shaking

antd 和 moment.js 是体积大户。替换 moment.js 为 day.js（轻量级替代，只有 2KB），并按需加载 antd 组件：

npm install dayjs antd @babel/plugin-transform-runtime --save
npm install babel-plugin-import --save-dev

配置 babel-plugin-import 按需加载 antd：

module.exports = {
  module: {
    rules: [
      {
        test: /\.js$/,
        use: {
          loader: 'babel-loader',
          options: {
            plugins: [
              ['import', { libraryName: 'antd', style: 'css' }], // 按需加载
            ],
          },
        },
      },
    ],
  },
};

在代码中：

import { Button } from 'antd';
import dayjs from 'dayjs';

console.log(dayjs().format('YYYY-MM-DD')); // 轻量级时间格式化

效果：antd 从 500KB 降到 100KB（只加载用到的组件），day.js 替换 moment.js 省下 290KB，bundle 总体积减少 40%！

10.4 优化加载体验

首页包含商品图片和推荐模块，用懒加载和预加载优化：

// src/home.js
function lazyLoadImages() {
  const images = document.querySelectorAll('.product-img');
  images.forEach((img) => {
    const observer = new IntersectionObserver((entries) => {
      if (entries[0].isIntersecting) {
        img.src = img.dataset.src;
        observer.disconnect();
      }
    });
    observer.observe(img);
  });
}

document.getElementById('showRecommend').addEventListener('click', () => {
  import(/* webpackPreload: true */ './recommend.js').then((module) => {
    module.initRecommend();
  });
});

HTML 中添加预加载：

<link rel="preload" href="home.[contenthash].js" as="script">
<link rel="preload" href="main.[contenthash].css" as="style">
<img data-src="product1.webp" class="product-img" alt="商品">

10.5 长效缓存

配置 contenthash 和 runtimeChunk：

module.exports = {
  output: {
    filename: '[name].[contenthash].js',
    chunkFilename: '[name].[contenthash].chunk.js',
  },
  optimization: {
    runtimeChunk: {
      name: 'runtime',
    },
    splitChunks: {
      cacheGroups: {
        vendors: {
          test: /[\\/]node_modules[\\/]/,
          name: 'vendors',
          chunks: 'all',
        },
      },
    },
  },
};

效果：首屏加载时间从 5 秒降到 1.8 秒，二次访问因缓存命中几乎瞬开！

10.6 持续监控

在 CI 中集成 Lighthouse 和 webpack-stats-diff，确保每次提交不引入性能回归。最终，项目性能指标达到：

• FCP：1.8 秒

• TTI：2.5 秒

• Bundle 体积：从 2MB 降到 800KB

• 构建时间：从 20 秒降到 10 秒

小结：通过综合优化，这个电商项目的用户体验和开发效率都上了新台阶！