Performance面板数据是否可用80%取决于录制前准备：必须用无痕窗口、Network面板勾选Disable cache、设置CPU Throttling为4x、勾选Screenshots和Memory，且Record与Start profiling按钮不可混用。
Performance 面板录出来的数据是否可用，80% 取决于你点“Record”之前做了什么——不是操作多复杂，而是前置条件有没有卡死。
必须用无痕窗口 + 禁用缓存启动录制
插件、缓存、预加载脚本会污染主线程耗时，导致 Long Task 虚高或关键阶段（如 HTML 解析）直接消失。不是“建议”，是硬性前提：
- 按
Ctrl+Shift+N（Windows/Linux）或Cmd+Shift+N（macOS）开无痕窗口，再输入 URL - 打开 DevTools → 切到
Network面板 → 勾选Disable cache（这一步 Performance 面板里没有，必须单独设） - 不要在地址栏输完 URL 再打开 DevTools —— 这样会漏掉
navigationStart到DOMContentLoaded的全部解析过程
录制前必调的三项配置
右上角齿轮图标 ⚙️ 里的设置，不调等于白录：
-
CPU Throttling选4x slowdown：桌面端帧率太高，32ms的 JS 执行在火焰图里就是一条细线，拉长到128ms才能看清谁在拖慢主线程 - 勾选
Screenshots：没有帧截图，就无法把 FPS 曲线上的红条和实际画面卡顿（比如某帧突然变灰、撕裂）对应起来 - 勾选
Memory：DOM 节点突增、JS Heap 持续上涨、Detached DOM 不释放，这些都藏在内存曲线里，不勾就看不到
Record 和 Start profiling and reload page 的区别不能混
两个按钮触发的是完全不同的录制逻辑，选错就找不到你要查的问题：
立即学习“前端免费学习笔记（深入）”；
- 点左上角圆形
Record按钮：适合分析用户主动行为，比如点击按钮后动画卡顿、滚动列表掉帧。操作前立刻点，操作完成马上停，时长控制在2–5 秒内最清晰 - 点旁边的
Start profiling and reload page：只用于页面加载性能。它会在DOMContentLoaded和load后自动停，适合查首屏白屏、资源阻塞、JS 执行拖慢渲染。想看点击后的requestAnimationFrame却用了这个，调用栈根本不会出现
火焰图里找不到 parseHTML 或 layout 是正常现象
浏览器把底层解析（gumbo_parse()）、强制同步布局（Forced Synchronous Layout）做了聚合或隐藏，不代表没发生：
- 看到横跨 >
50ms的黄色块，先别急着点进去看 JS 函数——抬头看它上方标签：Layout表示重排，Recalculate Style是样式重算，Composite Layers是合成阻塞 - 若看到大量
Forced Synchronous Layout提示，大概率代码里有el.offsetHeight后紧跟el.style.top = ...这类读写交替 -
Parse HTML在火焰图里是一整块聚合任务，想精确定位瓶颈，得手动打标：performance.mark('parse-start')放在document.write前，performance.mark('parse-end')放在document.body可访问后
真正难的不是点下录制按钮，而是判断哪一段时间轴属于你的问题路径——比如 SPA 路由跳转，navigation 类型记录只在首次加载有效，后续必须用 performance.measure('route-change', 'nav-start', 'nav-end') 手动关联，否则 LCP/FID 时间戳和火焰图对不上。
