性能分析与构建提速
约 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,避免回退无人发现。
