Chrome DevTools Performance面板通过FPS曲线图和帧详情定位掉帧：绿色满高条表示60FPS稳定，红区或绿条变矮表明单帧超16.6ms；帧模式中深绿（≤16ms）、黄（16–25ms）、红（＞25ms）对应耗时，点击可查JS/Style/Layout/Paint/Composite各阶段瓶颈；事件模式助区分JS执行或渲染问题，优化后对比FPS与单帧耗时即可验证效果。
Chrome DevTools 中的 Timeline（现为 Performance 面板）是分析帧率变化最直接的工具。它的核心目标就是帮你判断动画或交互是否稳定维持在 60 FPS，以及掉帧发生在哪个环节。
关键看 FPS 图表和帧详情
打开 Performance 面板（F12 → Performance 标签），点击录制按钮（●），操作页面后再次点击停止。分析时重点关注顶部的 FPS 曲线图——它用绿色横条表示每秒实际帧数，高度对应数值，红色区域代表低于 60 FPS 的掉帧。
- 绿色条满高且连续：帧率稳定，渲染顺畅
- 出现短红条或绿条明显变矮：单帧耗时超 16.6ms，发生掉帧
- 连续红区：严重卡顿，需重点排查
切换到帧模式（Frame Mode）定位问题帧
录制结束后，在时间轴上方选择“Frames”视图（或点击右上角齿轮 → “Show frames”）。你会看到一个个小方块，每个代表一帧，颜色反映渲染耗时：
- 深绿色：≤ 16ms，达标
- 黄色：16–25ms，勉强可接受
- 红色：＞25ms，明显卡顿
点击任一红/黄帧，下方会显示该帧完整的渲染流水线：JS → Style → Layout → Paint → Composite。展开每项，就能看到具体哪一步耗时异常——比如 Layout 时间飙升，说明存在强制重排；Paint 占比过高，可能样式频繁变更触发大量重绘。
结合事件模式快速归因
若想进一步区分是 JS 执行拖慢，还是渲染本身出问题，可切回“Events”模式。这里按类型分组展示任务：Animation Frame Callback、Layout、Paint、Composite Layers 等。长时间的 JS 调用块通常意味着脚本逻辑过重；密集的 Layout/Paint 条目则指向样式或 DOM 操作不当。
- 查看
rAF回调是否准时触发（间隔是否接近 16.6ms） - 注意是否有
Forced Synchronous Layout提示（即 JS 中读取 offsetTop 等布局属性后立即修改样式） - 观察
Composite是否频繁发生，或某帧中出现多层 Paint → 可能未启用 GPU 加速
验证优化效果很简单
改完代码后，重新录制同一操作路径，对比前后 FPS 曲线和单帧耗时分布。只要红区减少、绿色条更饱满、单帧 Layout/Paint 时间下降，就说明优化有效。
不复杂但容易忽略
