firefox devtools性能分析器专为诊断交互卡顿设计，通过录制主线程活动、分析fps曲线、调用栈耗时及事件与渲染帧交叉验证来定位js执行、重排重绘等瓶颈。
Firefox DevTools 的性能分析器（Performance panel）专为诊断交互卡顿、响应迟缓等运行时问题而设计，核心在于捕获并可视化主线程活动。它不只看加载速度，更聚焦用户操作后页面是否跟手、动画是否掉帧、点击是否有延迟。
打开并启动性能记录
按 Shift+F5（Windows/macOS）直接打开性能分析器，或通过菜单栏「工具 → Web 开发者 → 性能」进入。确保右上角「启用 JavaScript 分析器」已勾选——这是识别 JS 执行瓶颈的关键。点击「开始录制」按钮，然后在页面上执行目标交互动作（如点击按钮、滚动列表、拖拽元素），持续 3–5 秒后点击「停止录制」。
重点观察 FPS 和主线程阻塞
录制完成后，顶部会显示实时帧率（FPS）曲线图。绿色表示流畅（≥60 FPS），黄色/红色区域代表掉帧。把鼠标悬停在低 FPS 区域，下方瀑布图会高亮对应时间段的主线程活动：
- 长条状的黄色块：JavaScript 执行时间过长，可能有复杂计算、未优化循环或同步 DOM 操作
- 连续密集的紫色块：频繁重排（layout）或重绘（paint），常见于内联样式修改、offsetTop 等强制同步布局读取
- 大片空白+突然爆发：事件处理函数被批量触发（如 scroll 或 input 未节流）
定位具体耗时函数
切换到「调用栈」（Call Stack）视图，展开顶部最宽的函数节点。它会逐层显示调用链，右侧标注每个函数的自用时间（Self Time）和总耗时（Total Time）。优先关注 Self Time 高的函数——它们是真正消耗 CPU 的“元凶”，比如：
- render() 或 update() 耗时 80ms：说明组件更新逻辑过重，需检查是否重复渲染、未使用 shouldComponentUpdate / v-memo
- getBoundingClientRect() 出现在高频滚动中：应缓存结果或改用 IntersectionObserver
- JSON.parse() 或大型数组 .map() 在响应事件中执行：考虑懒处理、Web Worker 或分片执行
结合事件与渲染帧交叉验证
在时间轴底部，可开启「事件」（Events）和「渲染帧」（Frames）轨道。拖动查看某次点击事件触发后，是否在 100ms 内完成响应（FID 原则），以及后续几帧是否出现 layout/paint 延迟。若点击后 200ms 才开始绘制，说明 JS 主线程被阻塞，需检查事件监听器中是否存在同步阻塞操作。
