直接打开performance面板并规范录制可生成可交互报告；需用隐身窗口、禁用缓存、开启screenshots/memory、cpu 4x节流，点击“reload and record”按钮捕获完整生命周期。
直接打开 Performance 面板并完成一次规范录制，就能生成可交互的页面性能报告。关键不在“怎么打开”，而在于“怎么录才准、怎么看才懂”。
用隐身窗口启动，禁用缓存再录制
真实性能问题常被插件、缓存或后台脚本掩盖。必须：
- 按 Ctrl+Shift+N（Windows/Linux）或 Cmd+Shift+N（Mac）新建隐身窗口
- 打开目标网页后，按 F12 打开 DevTools，切到 Performance 标签页
- 点击右上角齿轮图标，勾选 Screenshots 和 Memory，CPU 节流选 4x slowdown
- 在左上角勾选 Disable cache（这个选项在齿轮设置里，不是 Network 面板）
- 点击带刷新图标的按钮（Reload and record），而不是单独点红色圆点——它能捕获从导航开始的完整生命周期
报告生成后，先看 Overview 区域三根主线
顶部概览图是快速判断瓶颈的入口：
- FPS 曲线中出现红色竖条 → 该帧耗时 >16.7ms，已掉帧
- CPU 图表里紫色（Rendering）或黄色（Scripting）区域持续堆高 → 渲染或 JS 执行过载
- NET 行中某资源横杠特别长，且浅色部分（等待时间）占比大 → TTFB 高，问题可能在服务端或网络
聚焦 Main 火焰图，定位具体函数
卡顿根源藏在主线程执行细节里：
- 找宽度明显超过 50ms 的长条（尤其标红或深黄），拖选它，时间轴自动缩放
- 切到下方 Call Tree 标签页，按 Self Time 降序排列
- 展开耗时最高的函数，逐级下钻，直到看到你自己的业务代码行号或第三方库方法名
- 若某函数 Self Time 占比高但调用次数少，说明单次执行太重；若占比不高但总 Time 高，可能是高频调用累积
联动 Network 面板验证瓶颈归属
Performance 报告只告诉你“主线程忙”，但未必是 JS 的锅：
- 如果主线程空闲时段页面仍卡，立刻切到 Network 面板，重新按 Ctrl+E 录制
- 对比同一操作下：TTFB >500ms → 后端或 CDN 问题；FCP 远晚于 DOMContentLoaded → CSS 阻塞渲染或关键资源未预加载
- 某个 JS 文件在 Network 里加载慢 + 在 Performance 里执行久 → 双重瓶颈，需拆包 + 延迟加载
不复杂但容易忽略。
