Chrome Performance面板的Screenshots功能是定位渲染卡顿的核心视觉锚点，通过帧画面与时间轴精确对应，结合FPS曲线、Main轨道调用栈及优化前后截图比对，可精准识别并验证卡顿帧及其根本原因。
Chrome Performance 面板的 Screenshots 功能不是辅助功能，而是定位渲染卡顿最直观的“视觉锚点”——它把毫秒级的时间轴和真实帧画面一一对应，让你一眼看出“哪一帧卡了、卡成什么样、为什么卡”。
开启 Screenshots 并确保截图有效
录制前必须手动启用，否则默认关闭：
- 打开 Performance 面板 → 点击右上角齿轮图标 → 勾选 Screenshots
- 务必在隐身窗口中操作，避免插件或缓存干扰截图生成
- 若截图稀疏或缺失（比如只有开头/结尾几张），检查是否误开了 “Throttling” 中的 extreme 模式，或页面存在 canvas 全屏覆盖、WebGL 渲染等屏蔽截图的场景
用截图对齐 FPS 曲线找卡顿帧
FPS 轨道上的红色低帧区域只是提示“可能卡”，真正确认要靠截图对比：
- 将鼠标悬停在 FPS 图表某段红色/黄色低帧区域，下方 Summary 会显示该帧耗时（如 42ms）
- 同时观察右侧 Frames 区域中对应时间点的缩略图：如果前后两帧画面几乎一样，但中间隔了一张模糊/撕裂/空白图，说明这一帧没及时渲染完成
- 特别关注“输入响应后第一帧”：比如点击按钮后，截图里出现 100ms 的静止画面，再突然跳到新状态——这就是典型的输入延迟卡顿
结合 Main 轨道与截图锁定瓶颈函数
截图帮你定位“哪一帧”，Main 轨道帮你定位“为什么卡”：
- 在 Frames 区域找到卡顿帧对应的时间点（例如 2.34s 处）
- 切换到下方 Main 轨道，拖动时间轴放大该时刻前后 50ms 的调用栈
- 找到其中一段紧凑的黄色块（Scripting）或紫色块（Layout），右键 → Zoom to selection
- 展开 Call Tree，按 Self Time 排序，看哪个函数独占最多时间——比如某个
getBoundingClientRect()调用触发了 Forced Layout，且紧邻截图中画面冻结的起始点
横向比对优化效果（截图是关键证据）
改完代码后不能只看 FPS 数字提升，要用截图验证是否真解决了视觉卡顿：
- 两次录制都开启 Screenshots + 4x CPU Throttling + Disable cache，操作路径完全一致
- 并排查看优化前后的帧缩略图：原来卡顿处的“重复静止帧”是否减少？画面过渡是否更连贯？
- 如果 FPS 数值相近但截图明显更顺滑，说明你优化的是感知性能（Perceived Performance），这比单纯压低耗时更有价值
