直接查看 performance.getEntriesByType('navigation') 和 'resource' 可定位80%加载瓶颈，但主线程阻塞与长任务更隐蔽；需结合 navigation 阶段拆解、resource 慢资源排查、PerformanceObserver 监听长任务/LCP/FID、requestIdleCallback 与强制重排测布局成本，并多次测量取中位数。
直接看 performance.getEntriesByType('navigation') 和 performance.getEntriesByType('resource')，就能定位 80% 的加载瓶颈；但多数人漏掉了主线程阻塞和长任务这两个更隐蔽的卡顿根源。
查 navigation 条目确认首屏关键路径耗时
页面加载慢，不能只盯着“白屏时间”，得拆解成 TTFB、DNS、TCP、SSL、响应体传输、DOM 解析、样式计算等阶段。这些全在 navigation 条目里，但必须用现代接口读取。
-
performance.getEntriesByType('navigation')返回数组，取[0]即可；performance.timing已废弃，别再用 - 重点关注
responseStart - navigationStart（TTFB），超过 800ms 就该查后端或 CDN -
domContentLoadedEventEnd - responseEnd反映 DOM 解析+同步 JS 执行耗时，若 > 300ms，检查是否含未拆分的大型 inline 脚本 -
loadEventEnd - domContentLoadedEventEnd高说明有大量异步资源（图片、iframe）拖慢整体完成，需结合 resource 条目交叉验证
扫 resource 条目揪出拖慢首屏的“慢资源”
很多性能问题不是代码写的差，而是某个第三方脚本或字体加载卡了 2 秒——它不会报错，但会把 FCP 推后整整一拍。
- 执行
performance.getEntriesByType('resource')后，按duration倒序排列，一眼看出谁最慢 - 特别注意
initiatorType === 'script'或'link'且name指向 CDN 或第三方域名的条目 - 对比
connectStart和secureConnectionStart：若差值大（> 150ms），说明 TLS 握手慢，可能需开启 HTTP/2 或预连接 - 字体资源（
initiatorType === 'css'+name含 .woff2）若duration> 400ms，考虑font-display: swap或预加载
用 PerformanceObserver 捕获长任务与核心指标
用户觉得“卡”，往往不是加载慢，而是主线程被某段 JS 锁死 120ms —— 这种问题在控制台里不报错，靠肉眼也看不出，只能靠 longtask 类型监听。
立即学习“前端免费学习笔记（深入）”；
- 必须用
PerformanceObserver，不能轮询performance.getEntriesByType('longtask')，因为条目是异步写入的 - 注册时加
{ entryTypes: ['longtask', 'largest-contentful-paint', 'first-input'] }，一次拿到 LCP、FID、长任务三类数据 - 长任务
duration> 50ms 就算风险项；连续出现多个 > 100ms 的任务，大概率是 React 渲染、复杂计算或未节流的 resize 监听器导致 - 注意：Chrome 需启用
--enable-blink-features=InteractiveRenderBlocking才能捕获部分渲染阻塞任务（仅开发调试用）
测主线程空闲与重排成本，识别隐性布局瓶颈
有些页面加载快、资源少，但滚动或输入时掉帧——问题不在网络或 JS 执行，而在频繁触发重排（reflow）或重绘（repaint），而这类开销不会出现在 resource 或 navigation 里。
- 用
requestIdleCallback测空闲延迟：performance.now()记录起始，回调里再记一次，差值 > 50ms 表示主线程长期无空档 - 手动触发重排测布局成本：读取
offsetHeight或getComputedStyle(el).height后立即写样式，再用performance.now()包裹，> 4ms 就属高危（60fps 下每帧仅 16.6ms） -
performance.memory在 Chrome 启动参数--enable-precise-memory-info下才可用；若usedJSHeapSize / totalJSHeapSize > 0.85，说明内存压力大，GC 频繁也会导致卡顿 - 别依赖单次测量：所有上述操作至少重复 3 次，取中位数；移动端尤其要切到“Slow 3G”+“4x CPU slowdown”下复现
真正难定位的瓶颈，往往藏在长任务和强制同步布局的组合里——比如一个 scroll 事件监听器里既调用了 offsetTop 又更新了 20 个元素的 class，这种问题不会出现在任何单维度报表中，只能靠交叉比对 longtask 时间戳和重排触发点的时间差来锁定。
