性能分析与构建提速
约 484 字大约 2 分钟
2026-02-11
性能优化最容易犯的错是“没测先调”。
这章的重点是建立一个可复用流程：
- 先观测。
- 再定位。
- 然后优化。
- 最后回归验证。
第一步：先把数据拿到手
常见指标至少包含：
- 冷启动构建时长。
- 增量构建时长。
- 首包体积与最大 chunk。
- 构建阶段耗时（loader/plugin）。
安装工具：
pnpm add -D webpack-bundle-analyzer progress-bar-webpack-plugin speed-measure-webpack-plugin示例配置：
const { BundleAnalyzerPlugin } = require('webpack-bundle-analyzer');
const ProgressBarPlugin = require('progress-bar-webpack-plugin');
module.exports = {
plugins: [
new ProgressBarPlugin(),
new BundleAnalyzerPlugin({
analyzerMode: 'static',
openAnalyzer: false,
reportFilename: 'report.html',
}),
],
};第二步：构建提速高收益项
不是所有优化都值得做，优先做“低风险高收益”的：
- 持久化缓存。
- 缩小 loader 命中范围。
- 优化
resolve解析成本。
const path = require('node:path');
module.exports = {
cache: {
type: 'filesystem',
},
resolve: {
extensions: ['.js', '.ts'],
alias: {
'@': path.resolve(__dirname, 'src'),
},
},
module: {
rules: [
{
test: /\.[jt]sx?$/,
include: path.resolve(__dirname, 'src'),
exclude: /node_modules/,
use: ['babel-loader'],
},
],
},
};thread-loader 要不要上
它不是必选项，而是“重转换场景可选项”。
- 模块数量不大时，线程通信开销可能大于收益。
- 只有在 Babel/TS 等转换确实成为瓶颈时再引入。
推荐排查顺序
排查流程
- 看总时长：先判断是冷启动慢还是增量慢。
- 看体积：找到最大包和重复包。
- 看阶段：定位是 loader 慢还是 plugin 慢。
- 小步优化：每次只改一个变量。
- 回归验证：记录优化前后数据。
常见误区
- 每次构建都开全量分析插件。
- 项目很小时盲目并行化。
- 不记录基线，最后无法证明优化是否有效。
最佳实践
- 建立固定性能基线文件（体积、构建时长）。
- 优化动作和收益做成可追踪记录。
- 把性能检查加入 CI，避免回退无人发现。