前端性能优化实战：从5秒到0.5秒的Webpack打包全攻略

1. 先搞清楚时间都去哪儿了：性能分析这一步不能省

接手这个项目的时候，线上首屏加载时间稳定在 5 秒左右，还是用的高速宽带。如果你也遇到过类似情况，第一反应可能跟我一样：先去找后端要接口耗时，或者怀疑是图片太大。但实际上，那次优化的最大瓶颈恰恰出在前端打包产物上——单页应用的首屏要等整包 JS 下载完才能渲染，而那个 bundle 当时已经膨胀到了 1.2MB 左右，光 gzip 下载就要掉一截时间。

前端性能优化最忌讳的就是凭感觉下手。我见过不少同学一上来就开 optimization.splitChunks，把 node_modules 一顿拆分，结果拆完体积没变，反而因为请求数暴增让首屏更慢了。正确的做法是先量化问题，用数据告诉自己没有优化的方向。我常用的工具组合其实很简单：

• Chrome DevTools 的 Lighthouse，快速生成一份性能报告，拿到 FCP、LCP、TTI 等核心指标；
• Webpack Bundle Analyzer，把打包产物按体积可视化，一眼找出体积大头；
• Performance 面板录制页面加载过程，定位长任务（Long Task）和 JS 执行阻塞。

那次我跑完 Lighthouse 之后，关键数据是这样的：FCP 大约 2.8 秒，LCP 大约 4.2 秒，TTI 更是超过了 5 秒。再把 Bundle Analyzer 打开，好家伙，整个 bundle 里 echarts 占了 350KB，moment 占了 220KB，lodash 全量引入占了 150KB，剩下的业务代码也普遍没有做按需加载。这就是典型的“能用能跑，但根本不敢做性能测试”的状态。

1.1 先量化再动手：五分钟摸清项目家底

给项目做性能分析，我不会一上来就改配置，而是先花个五到十分钟把“家底”摸清楚。下面这几个步骤基本是固定的：

打开 Chrome 的无痕模式，进入页面前先清空缓存，然后打开 DevTools 的 Network 面板，勾选 “Disable cache”，刷新页面，记录下首屏请求的数量、总传输体积、每个关键 JS/CSS 文件的加载耗时。重点看那几个超过 200KB 的文件，它们往往就是首屏加载的元凶。

接着跑一次 Lighthouse。不需要太复杂的配置，直接用默认的移动端模拟就行。注意 Lighthouse 的结果在弱网模拟下会偏高，但它的价值在于给你一个可横向对比的基线分数，后面每改一版配置，重新跑一次，就能看到分数变化。我当时定的目标是 Lighthouse Performance 至少到 85 分以上。

最后一步是用 Bundle Analyzer。如果你项目里还没配，直接加一个依赖就能跑：

bash复制npm install --save-dev webpack-bundle-analyzer

然后在 webpack 配置文件里加上对应插件，运行构建后它会自动打开一个可视化页面，左边是文件树，面积越大代表体积越大，可以非常直观地看出哪一个依赖包是“体积刺客”。这一步的产出不是优化方案，而是一份问题清单——知道要处理哪些东西，才知道怎么排优先级。

1.2 首屏 5 秒的元凶：不止是体积大

做完分析之后，我把首屏慢的原因归纳成了四类，这也是我后来制定优化方案的依据。

第一类是 bundle 体积过大，而且是“单体大包”模式。整个应用只有一个入口文件，所有页面、所有组件、所有第三方库全都打进了一个 JS 文件里，导致浏览器必须等这个文件完全下载并执行完，才能渲染首屏。这种模式在小型项目里没什么问题，但规模一上来，体积和加载时间就会线性增长。

第二类是第三方库使用方式不对。moment 直接全量引入，lodash 用 import _ from 'lodash' 的方式引入，echarts 也没有按需注册图表组件，这三个包加起来占了 bundle 的接近一半体积。而它们实际用到的功能可能连 20% 都不到，这就是纯浪费。

第三类是完全没有缓存策略。打包产物文件名用的是 main.js、app.js 这种固定名称，只要业务代码改了一行，整个文件重新生成，浏览器缓存全部失效，用户每次发版都要重新下载全量资源。

第四类是长任务阻塞渲染。Performance 面板录制显示，主线程在加载初期有一个将近 800ms 的 Long Task，排查后发现是某个模块在初始化时对一组比较大的结构化数据做了 JSON.stringify 序列化，而且这个序列化发生在页面渲染的关键路径上。这就带出了很多项目都会遇到的坑：JSON.stringify 用起来很简单，但在数据量大、嵌套深的场景下，它的耗时和内存占用都不可忽视。

把问题量化到这一步，“6 件事”的优化方向也就自然出来了。下面我按实际执行的顺序，逐个拆解具体的操作和配置。

2. 第一件事：按需引入 + 消除多余代码，从源头减少体积

很多人一想到性能优化，第一反应就是开 gzip、上 CDN，这些当然都有用，但它们属于“运输环节”的优化。我更习惯先处理“生产环节”的问题——代码能不能更少？如果源头就少了几百 KB，后面的压缩、缓存策略效果都会更好。

2.1 从 moment 到 dayjs：替换体积大户

在 Bundle Analyzer 里看到 moment 占了 220KB，几乎是整个 bundle 的五分之一，当时我就知道必须动它。moment 本身功能强大，但体积也大，而且它默认把所有语言包都打包进去了。项目中我们只用到日期格式化、相对时间和时间戳转换这些基础功能，完全可以用 dayjs 替代。

替换过程比想象中简单。dayjs 的 API 和 moment 高度兼容，大部分代码只需要改 import 语句：

javascript复制// 之前
import moment from 'moment';
moment().format('YYYY-MM-DD HH:mm:ss');

// 之后
import dayjs from 'dayjs';
dayjs().format('YYYY-MM-DD HH:mm:ss');

如果项目里有一些用了 moment 特有的插件功能，比如 relativeTime，在 dayjs 里也有对应的插件，按需引入即可：

javascript复制import relativeTime from 'dayjs/plugin/relativeTime';
dayjs.extend(relativeTime);

这一步之后，bundle 体积直接减少了约 200KB。对于这种“功能相同、体积减半甚至减到十分之一”的库替换，我建议优先级排到最高，性价比非常可观。组件库、工具函数库也同理，你在 analyze 页面上看到的每一个大面积色块，都值得审视一遍。

2.2 Tree Shaking 没生效？问题多半出在引入方式

把 lodash 全量引入换成按需引入，是另外一个性价比极高的改动。那时候项目里大量代码是这么写的：

javascript复制import _ from 'lodash';
_.debounce(fn, 300);
_.throttle(fn, 500);

这种写法在 webpack 里基本没法做 Tree Shaking，因为 import _ from 'lodash' 引入的是整个库的入口文件，不管你有没有用到其他函数，webpack 都会把整个 lodash 打包进去。改成下面两种方式之一，效果会好很多：

javascript复制// 方式一：按需引入具体函数
import debounce from 'lodash/debounce';
import throttle from 'lodash/throttle';

// 方式二：使用 lodash-es
import { debounce, throttle } from 'lodash-es';

我实际选择的是方式二，因为项目里用到的 lodash 函数比较多，逐个改成子路径引入太繁琐，而 lodash-es 保留了 ES Module 结构，webpack 可以正确识别并摇树。不过要注意，从 lodash-es 全量 import { debounce } from 'lodash-es' 这种写法虽然能触发 Tree Shaking，但如果项目中同时存在 lodash 和 lodash-es，要确保统一，混用会造成重复打包。

同理，echarts 也需要按需引入。echarts 的完整包非常大，正确做法是按需注册你实际用到的图表和组件：

javascript复制import * as echarts from 'echarts/core';
import { BarChart, LineChart } from 'echarts/charts';
import {
  TitleComponent,
  TooltipComponent,
  GridComponent
} from 'echarts/components';
import { CanvasRenderer } from 'echarts/renderers';

echarts.use([
  BarChart,
  LineChart,
  TitleComponent,
  TooltipComponent,
  GridComponent,
  CanvasRenderer
]);

这三轮按需引入做完之后，bundle 从 1.2MB 左右降到了 500KB 左右，似乎已经立竿见影了。但真正的重头戏还在后面，那就是拆包。

2.3 JSON.stringify 的隐藏成本：一次长任务排查

前面提到 Performance 面板发现的接近 800ms 的 Long Task，具体定位后发现是一个详情页的初始化逻辑里，对一份从接口返回的树形配置数据做了深度处理，中间用 JSON.stringify 做了一次深拷贝。

我把它单独拿出来说，是因为 JSON.stringify 相关的性能问题在不少项目里都存在，但很少被人注意。JSON.stringify 本身不是不能用，而是在处理大对象、循环引用对象、或者需要深拷贝的场景时，它有几个隐患：

第一，JSON.stringify 会序列化对象中所有可枚举属性，数据量大、层级深时耗时明显。第二，如果对象里存在 undefined、Function、Symbol，这些值会被直接忽略；存在 Date 会变成字符串；存在循环引用会直接抛错。第三，当 JSON.stringify 出现在主线程且数据量又大的时候，页面会有明显卡顿。

我当时的处理方式，是把 JSON 序列化操作从关键渲染路径上挪出去。两个方向：一是把深拷贝逻辑换成 structuredClone，它是浏览器原生支持的深拷贝 API，比 JSON 方案性能更好，也不会丢 undefined 和 Function 以外的复杂类型；二是如果这个序列化是不得已要做的，就把它塞进 setTimeout 或者 requestIdleCallback 里，不要阻塞首屏渲染。

javascript复制// 之前
const configCopy = JSON.parse(JSON.stringify(config));

// 之后
const configCopy = structuredClone(config);

这就是所谓“从源头减少体积”之外的另一个维度——减少主线程的执行时间。很多团队做性能优化只盯着 Network 面板，却忽略了 Performance 面板里的 JS 执行耗时。实际上，一个优化良好的页面，JS 执行时间应该控制在 300ms 以内，否则即便资源加载再快，用户还是会觉得卡。

3. 第二件事：路由懒加载 + splitChunks 分包，让首屏只加载需要的代码

按需引入解决了“同一个包里塞了太多用不到的东西”的问题，但还有一个问题没解决：整个应用的所有页面代码仍然打包在同一个文件里。用户访问登录页，却要把商品列表页、订单详情页、用户中心页的代码全部下载一遍，这显然不合理。解决办法就是路由懒加载和代码分割。

3.1 路由懒加载：从单文件到单页代码

webpack 从 4 开始原生支持基于 import() 的动态引入，配合 Vue Router 或 React Router 的懒加载语法，可以把每个路由对应的组件代码单独打包成一个 chunk，只有访问到对应路由时才加载。

以 Vue 项目为例，改造前后的对比是这样的：

javascript复制// 之前：所有路由组件都在主 bundle 里
import Home from '@/views/Home.vue';
import ProductList from '@/views/ProductList.vue';
import OrderDetail from '@/views/OrderDetail.vue';
import UserCenter from '@/views/UserCenter.vue';

const routes = [
  { path: '/', component: Home },
  { path: '/products', component: ProductList },
  { path: '/orders/:id', component: OrderDetail },
  { path: '/user', component: UserCenter }
];

javascript复制// 之后：按路由拆分 chunk
const routes = [
  { path: '/', component: () => import('@/views/Home.vue') },
  { path: '/products', component: () => import('@/views/ProductList.vue') },
  { path: '/orders/:id', component: () => import('@/views/OrderDetail.vue') },
  { path: '/user', component: () => import('@/views/UserCenter.vue') }
];

React 项目对应的是 React.lazy 和 Suspense：

javascript复制import { lazy, Suspense } from 'react';

const Home = lazy(() => import('@/pages/Home'));
const ProductList = lazy(() => import('@/pages/ProductList'));

function App() {
  return (
    <Suspense fallback={<Loading />}>
      <Routes>
        <Route path="/" element={<Home />} />
        <Route path="/products" element={<ProductList />} />
      </Routes>
    </Suspense>
  );
}

这一步改造之后，首屏请求的主 JS 文件只剩当前路由相关的代码，体积能从 500KB 降到不到 200KB。但懒加载只是代码分割的一半，另一半是缓存策略。如果你只是简单地动态引入，访问页面 A 时加载的 chunk，在访问页面 B 时可能会重新下载——因为它们的公共依赖被打包到了各自的 chunk 里。这就引出了 splitChunks 的配置。

3.2 splitChunks 配得好，缓存命中率才高

splitChunks 是 webpack 4 之后最强大的优化配置之一，也是很多人最容易配错的地方。我之前见过一个项目，为了拆包而拆包，把每个 node_modules 包都单独打成一个 chunk，结果页面加载时并发请求几十个 JS 文件，HTTP/1.1 下浏览器对同一域名最多同时建立 6 个连接，文件都在排队下载，性能反而倒退了。

一个比较稳健的配置思路是三层结构：第一层，业务代码按路由拆分，也就是上面说的懒加载；第二层，第三方依赖按权重拆分，把体积大、更新频率低的库单独打成几个 vendor chunk；第三层，业务公共代码抽成公共 chunk，避免每个路由都重复打包同一段组件代码。

我那次优化实际用的配置是这样：

javascript复制// webpack.config.js
module.exports = {
  // ...
  optimization: {
    splitChunks: {
      chunks: 'all',
      cacheGroups: {
        // 基础框架包
        vue: {
          test: /[\\/]node_modules[\\/](vue|vue-router|vuex|axios)[\\/]/,
          name: 'vendor-vue',
          priority: 30,
          enforce: true
        },
        // 图表库单独拆，因为体积大且大部分页面用不到
        echarts: {
          test: /[\\/]node_modules[\\/]echarts[\\/]/,
          name: 'vendor-echarts',
          priority: 20,
          enforce: true
        },
        // 其余 node_modules 依赖
        vendors: {
          test: /[\\/]node_modules[\\/]/,
          name: 'vendor',
          priority: 10
        },
        // 业务公共代码
        common: {
          name: 'common',
          minChunks: 2,
          priority: 5,
          reuseExistingChunk: true
        }
      }
    }
  }
};

有几个关键点值得展开。enforce: true 是强制拆包，因为默认情况下 splitChunks 对 chunk 的体积有 minSize 限制（默认 30KB），如果拆分出的包小于 30KB 就会被合并回去，加了 enforce 可以绕开这个限制，确保你想拆的一定拆出来。priority 用来处理 test 规则重叠的情况——所有 node_modules 都命中了 vendors，但 vue 和 echarts 组的优先级更高，优先被匹配。minChunks: 2 表示一个模块被多少入口依赖后才被抽进 common，这是避免公共代码拆得过碎的关键参数。

还要注意 HTTP 版本的问题。项目如果还在用 HTTP/1.1，chunk 数量不宜过多，目标是控制在 10 个以内；如果已经上了 HTTP/2，多几个 chunk 压力不大，因为可以多路复用。我配置完之后，配合路由懒加载，首屏需要加载的 JS 文件从 1 个变成了首屏路由 chunk + vendor-vue + vendor，总共 3 个，传输体积从 500KB 降到 180KB 左右。

4. 第三件事：Gzip 和 Brotli 压缩，让传输体积再减少一大截

代码体积从 1.2MB 降到 180KB，看起来已经很可观了，但浏览器实际下载的体积还能再降一半——只要开启压缩。HTTP 压缩是传输层的优化，它不影响代码运行逻辑，却能直接在网络上把文件变小，是我最推荐的“低风险高收益”优化项。

4.1 compression-webpack-plugin 配置：在构建时提前生成 .gz 文件

压缩可以在两个层面做：一是服务器实时压缩，比如 Nginx 开启 gzip on，每次请求都对文件进行压缩；二是在构建时预压缩，用 compression-webpack-plugin 在打包阶段直接生成 .gz 或 .br 文件，服务器只负责把预压缩文件发给浏览器。

我推荐第二种方式，原因有两个：第一，预压缩不消耗服务器 CPU，服务器实时压缩在高并发场景下会带来明显的 CPU 开销；第二，预压缩可以使用更高的压缩级别，压缩率更好，因为构建是一次性的，慢一点没关系。

配置方式如下：

bash复制npm install --save-dev compression-webpack-plugin

javascript复制// webpack.config.js
const CompressionPlugin = require('compression-webpack-plugin');

module.exports = {
  // ...
  plugins: [
    new CompressionPlugin({
      filename: '[path][base].gz',
      algorithm: 'gzip',
      test: /\.(js|css|html|svg)$/,
      threshold: 10240,
      minRatio: 0.8
    })
  ]
};

参数含义：test 指定只压缩 JS、CSS、HTML、SVG 这类文本资源；threshold 设为 10KB，小于这个体积的文件不压缩，因为小文件压缩后体积变化不大，反而会带来解压开销；minRatio 表示压缩后体积至少要比原来小 20%，否则就保留原文件。

如果你要同时支持 Brotli，再复制一份配置，把 algorithm 改成 'brotliCompress'，filename 改成 [path][base].br 即可。Brotli 的压缩率通常比 gzip 再高 15% 到 20%，但压缩耗时也更长，这更适合构建期预压缩。

4.2 服务器配置千万别漏：Nginx 优先返回 .br/.gz

文件生成之后，服务器得配一下，让它在收到请求时优先返回预压缩文件。以 Nginx 为例：

nginx复制gzip_static on;
gzip_types text/plain text/css application/javascript application/json image/svg+xml;

location /assets/ {
  brotli_static on;
  # 如果开启 brotli_static，Nginx 会优先返回 .br 文件
  # 没有 .br 文件时，回退到 .gz，再回退到原文件
}

这里有个很容易踩的坑：如果服务器同时配置了 gzip 实时压缩和 gzip_static，需要理解它们的优先级。gzip_static 是静态压缩，它只在磁盘上存在 .gz 文件时生效；Nginx 会先用它。brotli_static 同理，会优先于 gzip 返回 .br 文件。但前提是浏览器在请求头 Accept-Encoding 里声明支持，否则服务器不会返回压缩文件。你用 DevTools 的 Network 面板看请求响应的 Content-Encoding 字段，就能确认是否生效。

压缩做完之后，我对比了一次数据：180KB 的 JS 资源 gzip 后约 58KB，Brotli 后约 52KB。这个体积对于现代网络来说已经非常轻了，配合 HTTP 缓存，后续回访的时候几乎就是秒开。

还有一个小细节：压缩不仅对 JS/CSS 有效，对 JSON 接口响应同样有效。如果你的后端接口返回的数据量比较大，开启 Nginx 的 gzip_types 里加上 application/json，接口响应时间也会有明显改善。

5. 第四件事：contenthash 持久化缓存，让回访用户更快

优化完新用户的首屏加载，接下来要解决回访用户的加载体验。首屏加载慢一次还可以接受，如果每次访问都慢，那就是缓存策略出了问题——打包产物文件名没有变化，浏览器不知道文件更新了，于是重新下载全部资源。

缓存策略的核心是 contenthash。webpack 支持三种 hash 类型：hash、chunkhash、contenthash。hash 是每次构建全局生成的一个 hash，只要任何一个文件变了，所有文件名都变，缓存全部失效；chunkhash 是按 chunk 分组，chunk 内任何模块变了，整个 chunk 文件名都变，但同 chunk 下多个文件耦合在一起；contenthash 是精确到单个文件的，文件内容变了它才变。对于前端资源来说，contenthash 是唯一正确的选择。

5.1 配置 contenthash，让文件名精确反映内容变化

javascript复制// webpack.config.js
module.exports = {
  output: {
    filename: 'js/[name].[contenthash:8].js',
    chunkFilename: 'js/[name].[contenthash:8].chunk.js'
  }
};

:8 表示取 hash 的前 8 位，足够区分文件，又能避免文件名过长。这样配置之后，打包产物从 app.js 变成 app.3f8c2a91.js，业务代码只要没变，文件名就不会变，浏览器命中缓存，直接走本地资源。

但这里有一个很隐蔽的坑：runtime 和 manifest 问题。webpack 会把模块的引用关系、启动逻辑放到一个 runtime chunk 里，如果这个 chunk 和其他文件放在一起，那么你只改了一行业务代码，整个 runtime 会变，导致其他 chunk 也全部跟着失效。解决办法是单独拆出 runtime：

javascript复制module.exports = {
  optimization: {
    runtimeChunk: {
      name: 'runtime'
    }
  }
};

这样 runtime 单独成一个极小的文件，业务代码更新时，vendor 和 runtime 的 hash 不会变，浏览器只需要重新下载那个变化了的业务 chunk，其余全部命中缓存。这看起来是个小配置，实际上对回访用户的加载速度影响非常大。

5.2 构建缓存：不是给用户用的，是给自己用的

持久化缓存还有一个容易被忽略的维度：构建缓存。它的目的不是提升线上性能，而是缩短打包时间——开发体验和发版效率同样重要。我试过两种方案，一个是 thread-loader 配合多进程打包，另一个是 webpack 5 内置的 cache 配置。

webpack 5 已经内置了 cache: { type: 'filesystem' }，默认就会把构建中间结果缓存到 node_modules/.cache 目录，二次构建速度提升非常明显。如果你的项目还在用 webpack 4，可以考虑 hard-source-webpack-plugin，效果类似。

javascript复制// webpack.config.js
module.exports = {
  cache: {
    type: 'filesystem',
    buildDependencies: {
      config: [__filename]
    }
  }
};

buildDependencies 的作用是：当 webpack 配置文件本身变化时，缓存自动失效，避免旧的缓存影响新的配置。这个细节很多人会忽略，导致改了配置却看不到效果，排查半天发现是缓存问题。

构建缓存带来的效果非常直观：我那次优化后，首次构建大概 40 秒，第二次构建直接降到 8 秒左右。对于一天要发好几次版的团队来说，这省下来的时间积累起来很可观。

6. 第五件事：JavaScript 压缩与多线程构建，构建和运行双提速

这一件事的定位比较特殊，它同时关系到线上性能和本地构建效率。先说线上：代码分割和压缩这两个动作经常是绑在一起的，尤其是 webpack 5 默认使用 TerserWebpackPlugin 压缩 JavaScript，但默认配置不一定适合所有项目。再说本地：打包一次要 40 秒，改一行代码重新构建又要 40 秒，开发体验极差，所以并行构建也值得做。

6.1 TerserPlugin 的压缩配置：在体积和构建时间之间取平衡

webpack 4 之后，uglifyjs-webpack-plugin 基本退出舞台，terser-webpack-plugin 成为默认压缩器。它的好处是支持 ES6+ 语法，而 uglify 对新语法支持不好。默认配置下，webpack 就会用 Terser 做压缩，但一些参数值得显式配置：

javascript复制// webpack.config.js
const TerserPlugin = require('terser-webpack-plugin');

module.exports = {
  optimization: {
    minimize: true,
    minimizer: [
      new TerserPlugin({
        parallel: true,
        terserOptions: {
          compress: {
            drop_console: true,
            drop_debugger: true,
            pure_funcs: ['console.log']
          },
          format: {
            comments: false
          }
        }
      })
    ]
  }
};

parallel: true 表示开启多进程压缩，默认是 CPU 核心数减 1，多核机器上压缩速度能快好几倍。drop_console 会把 console.log 相关的代码直接删掉，在生产环境这是合理的，但要注意别误删了 console.error——线上问题排查还需要它。pure_funcs: ['console.log'] 是告诉 Terser，这些函数调用是“纯的”，可以安全移除。

这里有一个需要权衡的点：压缩等级越高，代码越小，但压缩耗时越长。对于大部分项目，默认的 compress 和 mangle 已经足够，不需要刻意追求极致压缩率，否则 CI 构建时间会被拖得很长。代码体积和构建效率的平衡点，需要根据自己的项目规模来定。

6.2 thread-loader：让构建过程用满 CPU

thread-loader 的原理，是把后续 loader 的处理放到 worker 池里并行执行。注意它是“后续 loader”的并行化——如果你把它放在前面，对 file-loader 这类不耗 CPU 的 loader 开启多线程意义不大；真正值得并行的是 babel-loader、ts-loader、sass-loader 这类需要做编译转换的 loader。

javascript复制// webpack.config.js
module.exports = {
  module: {
    rules: [
      {
        test: /\.js$/,
        exclude: /node_modules/,
        use: [
          'thread-loader',
          'babel-loader'
        ]
      },
      {
        test: /\.ts$/,
        exclude: /node_modules/,
        use: [
          'thread-loader',
          'ts-loader'
        ]
      }
    ]
  }
};

配置很简单，但注意几个坑。thread-loader 会带来额外的进程通信开销，如果项目很小，开启它反而更慢。一般来说，源码文件超过 500 个或者单次构建超过 20 秒的工程，才比较适合上多线程构建。另外，如果你用 ts-loader，需要把 transpileOnly 打开，否则类型检查会在每个 worker 里重复跑，反而拖慢速度。

我那个项目在加了 thread-loader 和缓存之后，二次构建从 40 秒降到 8 秒，首次构建也能跑到 20 秒以内。最关键的是，开发阶段的热更新速度也明显变快了，团队成员的开发体验改善了不少。

7. 第六件事：CDN 接入、预加载与性能预算，守住优化成果

到这一步，首屏从 5 秒到 0.5 秒的核心优化其实已经完成了。但这件“第六件事”我想放在最后讲，是因为它决定了优化成果能不能长期保持下去——CDN 解决了“从哪取资源”的问题，预加载解决了“什么时候取资源”的问题，性能预算则强制团队在后续迭代中不再制造新的性能问题。

7.1 静态资源上 CDN，至少要确认这三件事

项目里的 JS、CSS、图片、字体等静态资源，全部切到 CDN 之后，用户可以从离自己最近的边缘节点获取资源，而不是每次回源到你的服务器。但在切 CDN 之前，有三个问题必须先确认好。

第一是缓存策略。CDN 上资源的 Cache-Control 和 Expires 头要设置好，因为文件名已经带了 contenthash，所以可以放心用长缓存——我一般设置 Cache-Control: max-age=31536000, immutable，一年不动。第二是跨域问题。如果你把 JS/CSS 放到 CDN，并且某个静态资源要通过 JavaScript 访问，比如 fetch 请求，需要确保 CDN 返回了正确的 Access-Control-Allow-Origin 头。第三是回源问题。CDN 节点上没有命中缓存时，会回源到你的服务器拉取，要确认源站的带宽和稳定性能够支撑回源压力。

配置层面其实很简单，只需要改 output.publicPath：

javascript复制// webpack.config.js
module.exports = {
  output: {
    publicPath: process.env.NODE_ENV === 'production'
      ? 'https://cdn.example.com/assets/'
      : '/'
  }
};

所有生成的资源引用路径都会自动加上 CDN 域名前缀。要注意的是，本地开发和测试环境的 publicPath 不要也改成 CDN，否则本地起服务的时候资源全部走线上 CDN，调试会变得非常痛苦。

7.2 preload 和 preconnect：把等待时间提前利用起来

CDN 解决了资源下载的物理距离问题，但首屏加载时间还能再压缩一点，方法是把“资源的发现时间”提前。

其中 preload 是告诉浏览器，这个资源是当前页面必须的，尽快下载；preconnect 是提前和第三方域名建立连接，省去 DNS 查询、TCP 握手和 TLS 协商的时间。如果你的页面引用了第三方字体、外部 API 地址，preconnect 尤其有效。

Webpack 生态里有对应的插件 preload-webpack-plugin，但如果你用的 webpack 5，也可以直接用原生支持的 import() 魔法注释：

javascript复制// 对首屏关键的组件使用预加载
const Home = () => import(/* webpackPreload: true */ '@/views/Home.vue');

// 对可能访问的页面使用预获取，但不阻塞当前页面
const ProductList = () => import(/* webpackPrefetch: true */ '@/views/ProductList.vue');

webpackPreload 会让浏览器在当前页面加载的同时预加载指定 chunk，适合首屏必须要用的模块；webpackPrefetch 是在浏览器空闲时才去拉取，适合“用户接下来很可能会点”的模块。这两个魔法注释用起来成本极低，但对体验的提升是很实在的。

顺带一提，preconnect 的配置不需要放在 webpack 里，直接在 HTML 的 <head> 里加上就行：

html复制<link rel="preconnect" href="https://cdn.example.com" crossorigin>
<link rel="dns-prefetch" href="https://cdn.example.com">

dns-prefetch 是老牌方案，兼容性更好，preconnect 更激进，两者可以共存，不会冲突。

7.3 性能预算：防止优化成果在迭代中倒退

最后但很重要的是性能预算。没有预算约束的优化是不可持续的。你花了大力气从 5 秒优化到 0.5 秒，结果三个月后需求迭代，有人往首屏业务代码里加了个 300KB 的组件库，性能又被打回原形。

性能预算怎么落地？两个工具比较实用。第一个是 webpack-bundle-analyzer 的 threshold 模式，可以在构建时检查包的体积，超过设定的阈值就让 CI 报错。第二个是 lighthouse-ci，它可以把 Lighthouse 的分数和性能指标当成 CI 的门禁，每次提交代码自动跑一次性能测试，低于设定分数就打回。

举例，我用的 lighthouse-ci 预算配置文件大致是这样：

json复制{
  "ci": {
    "assert": {
      "categories": {
        "performance": ["error", { "minScore": 0.9 }]
      },
      "budgets": [
        {
          "resourceSizes": [
            {
              "resourceType": "total",
              "budget": 300000
            },
            {
              "resourceType": "script",
              "budget": 200000
            }
          ]
        }
      ]
    }
  }
}

这样就等于给团队立了一条规则：页面总资源体积不能超过 300KB，脚本体积不能超过 200KB，性能分数不能低于 90。有了这个约束，后续迭代时大家会主动关注引入的依赖体积和写法，而不是等性能报表出来才发现问题。

8. 常见问题与排查技巧实录

优化过程中踩过的坑，其实比顺利的部分更值得写下来。这一节我挑几个最典型的，按“问题—原因—解法”的方式列出来，方便你对照排查。

问题一：涉及浏览器缓存策略的坑

我在配置 contenthash 缓存之后，一度以为所有资源都能命中缓存。检查 CDN 的响应头发现，部分 JS 文件压根没走 CDN，而是直接访问了源站。原因是本地开发环境的 static 资源路径保存了旧的 publicPath，而 CDN 上的目录结构和本地构建不一致。解决方法是把所有环境变量梳理了一遍，确保 publicPath 在每个环境里都是正确的。

更常见的缓存问题是：改了一行业务代码，vendor 的 hash 也变了，导致所有第三方库重新下载。这就是 runtimeChunk 没单独拆出来导致的。如果你也遇到类似问题，优先检查 webpack 配置里有没有 runtimeChunk: { name: 'runtime' }，以及 optimization.splitChunks 里 vendor 的拆法是否合理。

问题二：多次分包反而更慢

splitChunks 配得太碎，导致请求数暴增，HTTP/1.1 下浏览器并发连接数受限，所有请求排队下载，页面加载反而比不拆包还慢。解决办法也很简单：把 HTTP 协议升级到 HTTP/2，或者控制 chunk 总数。

如果你现在还必须要兼容 HTTP/1.1，我建议采用最稳的策略：vendor 拆成 3 到 5 个大 chunk，业务代码按路由拆分，总请求数控制在 8 个以内。如果需要兼容的目标环境不支持 HTTP/2，这个策略基本不会出错。

问题三：长任务和内存占用偏高

首屏加载过程中，如果用户看到页面白屏后还卡了几百毫秒，多半是主线程有长任务阻塞了渲染。排查方法很简单：Performance 面板录制加载过程，看时间轴里有没有红色或黄色的长任务块，点击它能看到具体的调用栈，定位到是哪一个函数耗时最长。

我在项目里定位出的那个 JSON.stringify 耗时长任务，就是通过这种方式找到的。替换成 structuredClone 之后，长任务时间从接近 800ms 降到了不到 100ms。排查长任务有一个优先级思路：先看 JS 的解析和执行，再看样式计算和布局，最后看绘制。绝大多数首屏卡顿问题都出在 JS 解析执行这一环。

问题四：构建缓存导致的“改了配置没效果”

webpack 5 的 filesystem cache 在 node_modules/.cache 目录下，如果改了 loader 配置但旧缓存没有正确失效，就可能出现“明明改了配置，构建结果没变化”的情况。解决方法是配置 buildDependencies 自动追踪配置文件，或者在排查问题时手动删除 node_modules/.cache 目录重新构建。别迷信缓存，它偶尔也会误事。

我个人在优化过程中还有一个坚持了很久的习惯：每完成一个优化项，就跑一次 Lighthouse 并记录分数，同时记录 bundle 体积、请求数量、DOMContentLoaded 时间这几个关键数字。这些数据在写周报、向团队同步进展、和领导对齐目标时非常有用，也能让你清楚地知道每一项优化到底带来了多少收益。

从最初长期在 4 到 5 秒徘徊，到最后稳定在 0.5 秒左右，这个结果不是某一个配置带来的，而是体积分析、按需引入、代码分割、压缩传输、缓存策略、加载策略这些环节叠加的结果。每一步看起来都不复杂，但组合在一起，就能把首屏体验带到一个完全不同的量级。

如果你现在也在为项目加载慢发愁，我的建议是不要急着抄任何一份现成的配置，先花半天时间把性能分析工具跑起来，把问题量化清楚。然后按这篇文章的顺序，一步一步来，每一步跑一次数据对比。你会发现，前端性能优化不是一个玄学问题，而是一个通过数据驱动、可以逐步逼近最优解的过程。