chrome devtools performance 面板虽不支持自动对比，但可通过统一无痕窗口、禁用缓存、固定cpu节流、勾选screenshots/memory、一致操作路径实现可靠人工比对，并利用fps曲线、cpu轨道、长任务数、帧缩略图及火焰图定位优化层级。
Chrome DevTools 的 Performance 面板本身不直接支持“自动对比两次录制”，但通过规范操作+人工比对，完全可以实现可靠、可复现的性能对比。关键不在工具是否一键对比，而在每次录制条件严格一致、分析维度明确聚焦。
确保两次录制完全可比
若环境不同，对比就失去意义。必须统一以下五项：
- 无痕窗口启动：每次新开 Ctrl+Shift+N（Win/Linux）或 Cmd+Shift+N（Mac），避免插件、缓存、预加载脚本干扰
- Network 面板勾选 Disable cache：否则第二次录制可能走内存缓存，JS/HTML 加载时间虚低
- CPU Throttling 固定为 4x slowdown：不能一次选 4x、一次选 6x，否则耗时比例失真
- Screenshots 和 Memory 必须都勾选：才能比帧率波动、内存增长趋势、卡顿画面是否改善
- 操作路径与节奏一致：比如都从首页点击“搜索框”→输入“test”→回车→等待结果渲染完成，全程控制在 3–4 秒内
用同一份报告做横向指标比对
不必导出数据再 Excel 对比，DevTools 内就能高效比对：
- FPS 轨道看红条密度：顶部 FPS 曲线中红色竖条越少、绿色柱越高越稳，说明掉帧减少
- CPU 轨道看紫色/黄色堆积厚度：Rendering（紫）和 Scripting（黄）区域变薄，代表渲染与 JS 执行压力下降
- Main 火焰图找长任务数量：Summary 面板顶部显示 “X long tasks (≥ 50ms)”——这个数字下降最直观，比如从 18 降到 5
- Frames 缩略图逐帧对照：拖动时间轴，对比优化前后相同操作时刻的截图，看卡顿帧（灰块、撕裂、空白）是否消失
定位优化效果落在哪一层
看到整体指标变好后，要确认是哪类开销被削减：
- 若长任务里 Script Evaluation 宽度明显变窄，说明 JS 执行逻辑已优化（如减少循环、拆分大函数）
- 若 Layout 或 Recalculate Style 条变短，大概率消除了强制同步布局（比如把 el.offsetHeight 和 el.style.top = 分开写）
- 若 Composite Layers 阻塞减少，可能是减少了频繁触发图层重合成的操作（如过度使用 transform + opacity 组合）
- 若 内存曲线坡度变缓、Detached DOM 节点数下降，说明内存泄漏修复生效
进阶：用录制器（Recorder）固定用户流再对比
对复杂交互（如表单提交+弹窗+列表刷新），手动操作难保一致。可用内置 Recorder 工具：
- 打开 DevTools → 点击右上角 更多工具 → Recorder
- 创建并录制标准操作流（如“添加商品到购物车”）
- 分别在优化前、优化后版本中，用同一录制脚本自动重播，再各自录制 Performance 数据
- 这样保证了网络请求顺序、DOM 状态、事件触发时机完全一致，对比更可信
