Chrome DevTools Performance 录制后如何定位长任务

页面点击、输入或滚动后出现明显卡顿时，Performance 录制里的长任务通常是最值得先看的线索。打开 Chrome DevTools 的 Performance 面板，复现一次卡顿，在 Main 轨道找到带红色三角的任务，再用 Summary、Call tree 和 Bottom-up 逐层收窄范围。不要只看一条最长色块：先确认任务发生在主线程，再判断时间花在自己的脚本、样式/布局，还是第三方脚本上。

官方地址：https://developer.chrome.com/docs/devtools/performance/

1. 先把录制范围缩到一次可复现的卡顿

打开 DevTools，选择 Performance。如果标签页没有显示，可以按 Command+Shift+P（Windows、Linux、ChromeOS 使用 Control+Shift+P），输入 Performance panel，选择 Show Performance panel。

在 Performance > Capture settings 中只调整确实需要的 CPU 或 Network 模拟，然后点击 Start recording。立即执行一次能稳定复现卡顿的点击、输入或滚动，完成后点击 Stop recording。录制越短，后面在时间线上找长任务越容易；不要把多次无关操作混在一份 trace 里。

2. 在 Main 轨道先找带红色标记的任务

录制停止后，先在 Timeline overview 里拖选卡顿发生的时间段，再观察 Main 轨道。主线程活动以火焰图展示：横向是时间，纵向是调用栈，位于上方的活动会造成下方的子活动。

长任务会在右上角出现红色三角，并把超过 50ms 的部分用红色标出。点击这个任务，在下方 Summary 查看 Duration、Self duration、脚本来源、调用栈和时间分解。这里的 Duration 只能说明一次任务有多长，不等于已经找到了最应该修改的函数，所以要继续向调用关系展开。

一个实用的记录格式是：复现动作 / 任务总时长 / Self duration / 来源脚本 / 最深的业务函数。如果 Summary 只显示浏览器内部活动，先沿着调用栈向下展开，或打开 source map 后重新录制。

3. 用 Call tree 和 Bottom-up 判断时间到底花在哪里

选中同一段时间后，先看 Call tree。它从根活动出发，展示谁触发了后续工作；按 Total Time 排序，适合回答“哪次点击、事件或顶层任务造成了最多工作”。按 Self Time 排序，则能看到某个节点自身直接消耗的时间。

再切换到 Bottom-up。它把同一个活动在多个调用路径中的耗时聚合，适合回答“哪个函数或活动反复出现，累计直接占用了最多时间”。例如一个函数单次不长，但被多个事件调用，Bottom-up 可能比火焰图更快暴露它。

4. 排除第三方干扰并形成可复核结论

如果页面加载了分析脚本、广告脚本或组件库，点击 Performance 顶部操作栏的 Dim 3rd parties，第三方事件会变灰，第一方代码更容易被看见。没有选中事件时，还可以在 Summary 的 1st / 3rd party 表里比较各方的传输大小和主线程时间。

最后不要把“有一个 300ms 长任务”直接写成结论。应保存录制文件，并记录复现动作、选中的时间范围、Summary 的来源、Call tree 的根活动、Bottom-up 的最高 Self Time，以及第三方是否被置灰。这样下一次改代码后可以用同一动作再次录制，比较时间是否真的下降。

常见问题

红色三角是不是一定代表 JavaScript 写错了？

不是。长任务发生在主线程，可能来自脚本执行、样式计算、布局或绘制。先看 Summary 的活动类型和调用栈，再决定优化方向。

Call tree 和 Bottom-up 为什么数值不一样？

Call tree 保留从根活动向下的调用关系，Bottom-up 按活动聚合多条路径。两者统计视角不同，应在同一时间选择范围内配合使用。

录制后看不到自己的函数名怎么办？

先确认 JavaScript samples 没有关闭，再检查生产构建是否带有可用 source map。也可以先用脚本 URL、活动名称和 Event log 的发生顺序定位范围。

定位完成的标准不是找出最长的一块颜色，而是能把一次卡顿连接到具体事件、函数或外部脚本，并用同样的复现动作验证改动结果。