speed-measure-webpack-plugin通过包裹整个webpack配置对象，可在控制台直观展示各loader和插件的耗时明细，精准定位babel编译、css处理、代码压缩等构建瓶颈，是分析打包性能最直接有效的方式。
直接用 speed-measure-webpack-plugin 包裹 Webpack 配置，就能在控制台看到每个 loader 和插件的耗时明细，这是定位构建瓶颈最直接有效的方式。
安装与基础配置
执行安装命令：
npm install speed-measure-webpack-plugin --save-dev
在 webpack.config.js（或 Vue/React 项目的对应配置文件如 vue.config.js）中引入并包裹导出的配置：
- 不要只包裹部分配置，必须包裹整个最终导出对象（比如
configureWebpack或默认导出的 config） - 示例写法：
const SpeedMeasurePlugin = require('speed-measure-webpack-plugin');<br>const smp = new SpeedMeasurePlugin();<br><br>module.exports = smp.wrap({<br> entry: './src/index.js',<br> module: { /* ... */ },<br> plugins: [/* ... */]<br>});运行分析并识别关键耗时项
执行打包命令（如 npm run build），终端会输出带层级结构的耗时报告。重点关注以下几类高占比项：
- Babel-loader：常占 35%–45%，说明 JS 编译是主要瓶颈
-
CSS 相关 loader（如
sass-loader、css-loader）：中大型项目中合计可能超 20% - TerserWebpackPlugin（代码压缩）：生产环境常见耗时大户，尤其未做缓存或未限制 parallel 时
- file-loader / url-loader / asset modules：图片、字体等资源处理量大时明显拖慢
配合其他工具交叉验证
speed-measure-webpack-plugin 告诉你“谁慢”，但不直接说明“为什么慢”或“怎么减体积”。建议搭配使用：
- webpack-bundle-analyzer：分析产出 bundle 的模块组成和大小，确认是否引入了冗余大依赖（如全量 lodash、未按需引入的 UI 库）
-
webpack-stats-plugin 或
stats: 'verbose'：查看模块解析路径、重复打包、未生效的noParse等细节 - 注意：
speed-measure-webpack-plugin和webpack-bundle-analyzer本身会增加构建时间，仅在分析阶段启用，上线前务必移除
常见误操作提醒
避免以下配置错误导致分析失效或结果失真：
- 把
smp.wrap()错误地套在plugins: []数组里，而不是整个 config 对象上 - 在多配置（如 dev/prod 分离）场景下，只对其中一个配置使用，漏掉另一环境的分析
- 启用了持久化缓存（
cache: { type: 'filesystem' }）但未清空缓存就对比前后数据，导致耗时偏差 - 未关闭 source map（
devtool: false或productionSourceMap: false）就分析，其生成过程会显著干扰真实 loader 耗时排序
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
