先给出几个核心观点：利用 Chrome DevTools 的 Performance 面板进行性能瓶颈分析时，关键不在于录制速度多快，而在于录制是否精准、能否看懂数据、并做出正确优化。它并非“看一眼就能改代码”的简易工具，而是借助真实的运行时数据，帮助你发现——谁在拖慢主线程、卡顿何时发生、以及根本原因是什么。
一、先录对：两种录制方式不可混用
先不急于点击录制，首先要明确你想分析哪种场景。Performance 面板提供了两个入口，各自的目标截然不同：
- 点击圆形 Record 按钮（●）：适合分析用户主动操作带来的性能问题，例如点击按钮导致动画掉帧、滚动时卡顿、表单提交延迟。操作前启动录制，操作完成后立即停止。关键在于不要录太久，2–5 秒就足够了，否则数据过多反而难以分析。
- 点击“Start profiling and reload page”（带刷新图标的按钮）：专门用于分析页面加载阶段。该模式会自动在
DOMContentLoaded和load事件之后停止，适合定位首屏白屏、JS 阻塞解析、资源加载顺序等问题。
很多新手常犯一个错误：想排查点击后的动画，却用了 reload 录制，结果录到的是 HTML 解析和样式计算阶段，根本找不到你写的 requestAnimationFrame 或事件回调。方向不对，努力白费。
二、录之前必须做的三件事
如果跳过这些准备工作，录出的数据基本没有参考价值：
- 使用无痕窗口（Ctrl+Shift+N 或 Cmd+Shift+N）打开页面，避免浏览器插件干扰。这一步很容易被忽略，但很多奇怪的问题都是插件引发的。
- 在面板右上角 ⚙️ → CPU Throttling 中选择 4x slowdown 或 6x slowdown，模拟中低端设备的真实体验。桌面端的高帧率会掩盖移动端的卡顿，这一点非常关键。
- 务必勾选 Screenshots（截图）和 Memory（内存），否则无法将视觉卡顿与帧画面变化对应起来，也看不到内存是否持续增长。
三、重点看什么：主线程里真正耗时的是什么
打开时间轴后，主线程轨道上那些黄色长条，很多人第一反应是“JS 写得差”，但事实未必如此。需要仔细区分真正的瓶颈类型：
- Script Evaluation 占比高 → 进入 Bottom-Up 标签页，找到“Self Time”最高的函数（即它自身执行耗时，不含子调用），这才是最该优化的 JS 逻辑。
- 出现大量 Forced Synchronous Layout 提示 → 说明代码中存在读写交替，比如
el.offsetHeight后立刻设置el.style.top，浏览器被迫反复回流，这正是典型的性能陷阱。 - Recalculate Style 或 Layout 耗时突出 → 检查 CSS 选择器是否过于复杂（可用 SelectorStats 查看匹配耗时），或频繁修改影响样式的属性。
- Paint 或 Composite Layers 占比高 → 可能涉及大量图层合成、未启用硬件加速，或过度使用
will-change。
不要忽略 Summary 面板顶部那行小字：“12 long tasks (≥ 50ms)”。在 RAIL 模型中，超过 50ms 的任务会导致用户感知卡顿。点击任意一个 Long Task，确认它的起始时间是否与你的操作时刻吻合。
四、改完之后怎么验证
优化不是改完就结束，必须进行闭环验证：
- 保持相同的录制条件（同设备模式、同 CPU 限速、同交互路径），重新录制并进行对比。
- 重点关注 Long Tasks 数量是否减少、FPS 是否稳定在 60、主线程连续空闲时间是否延长。
- 如果优化了 JS 执行，但 FPS 仍然偏低，说明瓶颈可能已转移到渲染阶段（如 Paint/Composite），需要切换分析重点。
这些步骤并不复杂，但容易忽略，关键是每一步都要做到位。
