Chrome DevTools Performance用Main线程火焰图定位脚本耗时

页面卡顿时，先不要凭感觉猜某个函数慢。用 Chrome DevTools 的 Performance 面板录制一次范围明确的操作，再从 Main 线程火焰图的横向宽度找到长任务，最后用 Summary 和 Bottom-up 把总耗时收敛到具体脚本调用。

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

最稳的判断顺序是“先固定复现动作，再看 Main 轨道的宽度，最后比较 Self time 和 Total time”。火焰图负责告诉你哪里占时间，Bottom-up 负责告诉你哪些函数值得先改。

准备记录：先把任务窗口变成可比较的样本

打开 Chrome DevTools，进入 Performance。如果分析页面加载，选择录制并刷新；如果分析点击、筛选或滚动造成的卡顿，就先把页面放到稳定状态，再点击 Record。一次录制只保留一个目标动作，避免把切换标签、打开菜单等无关操作混进样本。

1. 路径：Chrome 菜单 > 更多工具 > 开发者工具 > Performance。
2. 路径：Performance > Capture settings。只有需要模拟低端设备时才设置 CPU 或 Network 节流；同一组对照必须使用相同设置。
3. 点击 Record，执行一次目标动作，动作结束后立即点击 Stop。不要为了“多采一点”连续操作多个功能。

成功的可比较样本应当出现 Main、Network、Frames 等轨道，时间轴范围只覆盖目标动作。若每次录制的起止位置差异很大，先缩小复现步骤，不要急着解释耗时数字。

从 Main 火焰图回到具体脚本调用

在 Main 轨道中，矩形的横向宽度代表活动占用的时间，纵向嵌套表示调用关系。先找出最宽的脚本活动，再单击它查看下方详情；不要只盯着颜色，也不要把最深的一层直接认定为根因。

1. 路径：Performance > Main track。先观察长任务所在的时间段，再逐层展开调用栈。
2. 选中长任务后查看 Summary，记录 Duration、Script activity 等信息，以及它属于哪一类活动。
3. 如果选中的是父级任务，继续点进耗时集中的子活动；如果多个子项都很短但父项很宽，说明需要转到聚合视图继续判断。

这一步的结果不是“找到一个最深函数”，而是得到一个可复述的范围：某次交互中，某个长任务占用了多少时间，Summary 将它归到了哪类脚本活动。

用 Bottom-up 区分自身慢与调用链慢

选择活动后切到 Bottom-up。这里从底层活动的聚合结果看耗时，适合回答“哪些函数反复贡献了时间”。重点比较两列：

例如某个函数 Self time 很小而 Total time 很大，优先排查它调用的子函数；反过来，Self time 本身就高，则应先减少自身计算量。不要把节流环境下的绝对毫秒数直接当作线上真实耗时，节流更适合做同条件前后对照。

保存 profile 并验证优化结果

第一次录制后使用 Performance 面板的 Save profile 保存原始样本。修改脚本后，重新执行完全相同的动作，再用 Load profile 打开旧样本对照。比较时固定页面数据、CPU/Network 设置、录制入口和操作边界，否则无法判断是代码变化还是样本变化造成的差异。

可以把结论写成一条短记录：目标动作、Main 长任务区间、Summary 类型、Bottom-up 中最值得处理的函数、修改后 Self/Total time 的变化。这样的记录比“页面感觉更快”更容易复盘，也方便后续继续定位。

常见问题

火焰图很宽，为什么看不到唯一根因？

宽任务可能包含多个相近耗时的子调用，也可能是父任务在等待下层工作。先用 Summary 确认选中范围，再用 Bottom-up 做聚合排序，不要只依赖视觉宽度。

是否应该一直开启 CPU 节流？

不应该。节流用于构造稳定的对照环境；定位线上真实体验时，还要保留接近用户设备的录制，并在文章或团队记录中写清节流倍率。