Chrome DevTools Performance 怎么录制长任务：Main 轨道、红色三角与回放核对

页面不是一直卡，而是点开筛选器后偶尔要等半秒，用户很容易误以为按钮没有响应。Chrome DevTools 的 Performance 面板特别适合处理这种“能复现、但不知道卡在哪里”的前端问题：录下一次完整交互，再把主线程轨道放大到具体的任务节点，最后回到页面重放确认问题根源。

先把“偶尔卡顿”变成一段可以回看的轨迹

这次以一个筛选面板为例：点击“应用筛选”后，列表需要重新计算一批节点，按钮会短暂失去响应。这里的目标不是得到一个漂亮的分数，而是回答三个具体问题：卡顿发生在什么时间段、主线程正在做什么、修复后这段轨迹是否真的变短。

Chrome 官方文档把 Performance 定义为 CPU 性能分析文件的录制和分析面板。它适合看运行时活动；页面加载指标或整体审计，则应另用 Lighthouse 等工具。

从 Command Menu 打开 Performance 面板

打开待测试页面，按 Cmd+Option+I（Windows/Linux 使用 Ctrl+Shift+I）打开 DevTools。顶部有 Performance 标签时直接点击；如果标签被折叠，可以按 Cmd+Shift+P 打开 Command Menu，输入 Show Performance，选择对应命令。

进入后先确认面板里能看到 Record、清除和录制设置等控件。不要在页面正在大量刷新、切换标签或打开弹窗的状态下开始录制，否则轨迹会混入无关操作。

只录一次交互：Record、触发、Stop

开始前把页面恢复到稳定状态。点击 Performance 面板的 Record，回到页面执行一次“打开筛选器—勾选条件—应用筛选”，等列表完成更新后再点 Stop。整段录制尽量只保留一个问题现场，后面放大时间轴时更容易分辨。

如果卡顿只在页面加载阶段出现，可以使用重新加载并自动录制的入口；如果问题发生在点击、输入或拖动，普通 Record 更合适。CPU 或网络节流会改变现象的强度，第一次定位不要急着打开，否则很难判断问题来自代码还是模拟环境。

录制停止后，Performance 会处理数据并显示报告。顶部概览区域通常有 FPS、CPU、NET 等轨道；中间是主线程活动；下方是 Summary 等详情。录制完成并不等于已经定位，只是把一次体验保存成了可选中的证据。

在 Main 轨道找到最长的 Task

Main 轨道展示渲染器主线程随时间发生的活动。先在概览区域拖选卡顿附近的时间段，再观察下方 Main 中横向最宽的条。条越宽，表示这项工作占用的时间越长；上下堆叠表示上层调用触发了下层工作。

带红色三角的 Task 值得优先查看，但它不是“看到就能下结论”的错误标记。选中这个 Task 后，看 Summary 里列出的耗时和活动类型，再展开 Call tree 或 Bottom-up，确认时间究竟花在脚本、样式重算、布局还是绘制。

可以用下面的顺序缩小范围：

把轨迹证据和修复动作对上

假设 Summary 指向一次点击后的脚本执行，Call tree 里同一个筛选回调反复出现在顶部。先记录原始录制的时间范围和 Task 时长，再修改代码。不要只看总页面时间就说“优化成功”，因为录制中可能还包括网络等待、动画或其他后台工作。

修复后用同样的页面数据和同样的操作顺序重新录制。第二段轨迹至少要回答：原来的长 Task 是否消失或变窄、Main 轨道是否仍有红色三角、点击后的视觉反馈是否恢复。若两次录制差异很大，先重复一次，避免把偶然的浏览器活动误当成收益。

// 记录每次录制的最小验收信息
const check = {
  action: 'apply-filter',
  beforeTaskMs: 0,
  afterTaskMs: 0,
  sameData: true,
  sameSteps: true
};

这段记录不是 DevTools 的导出格式，而是复盘时的最小对照表。真正重要的是同一操作、同一数据和同一观察口径。

常见问题

Performance 面板和 Lighthouse 是一回事吗？

不是。Performance 用录制轨迹分析运行时活动，Lighthouse 更偏向一组页面质量和性能审计。两者可以配合，但入口和证据不同。

看到红色三角就说明代码有 Bug 吗？

不一定。红色三角提示这段 Task 需要检查，最终仍要结合 Summary、调用链和页面体验判断。

录制时要不要同时打开 CPU 节流？

第一次复现建议保持默认环境，先确认真实问题。需要评估低端设备体验时，再单独使用节流并把设置写进对比记录。

为什么两次录制的时间不一样？

浏览器后台活动、缓存、网络和页面数据都会影响结果。保持步骤、数据和节流设置一致，并重复录制后再比较。

结束前做一次界面验收

关闭录制报告前，至少保存问题现场的时间段、最长 Task、Summary 结论和修复后的对照结果。这样下一位同事打开页面时，不需要凭感觉猜“哪里卡”，而能沿着 Performance、Main、Summary 三个界面位置复查。

Chrome DevTools 官方入口和术语可能随版本调整；若顶部标签位置变化，优先从 Command Menu 搜索 Performance，再按面板内的 Record、Main 和 Summary 重新建立操作路径。