Performance API 的正确使用关键在于时机、指标选择与数据解读：优先用 PerformanceObserver 监听 LCP/FID/CLS，用 navigation 类型获取准确导航耗时，resource 类型定位慢资源，User Timing 标记业务关键路径。

直接用 Performance API 做页面性能分析，关键不在“能不能”，而在“什么时候取、取什么、怎么用”。它不是一键出报告的工具，而是浏览器内置的精密计时器和事件记录仪——需要你明确目标、选对接口、避开常见陷阱。

优先监听核心指标（LCP/FID/CLS）

现代性能分析必须围绕用户可感知体验展开。Google 定义的 Core Web Vitals 是硬指标，Performance API 通过 PerformanceObserver 异步捕获最可靠：

• 监听 largest-contentful-paint 获取主内容渲染完成时间（LCP）
• 监听 first-input 捕获用户首次点击/输入的响应延迟（FID）
• 监听 layout-shift 累积所有意外布局偏移（CLS）
• 务必在页面初始化早期注册 observer，避免漏掉首屏关键事件

准确获取导航全过程耗时

想算 TTFB、白屏、可交互时间？别再读 performance.timing ——它已在主流浏览器中废弃且数据不准。改用：

• performance.getEntriesByType('navigation')[0]，它返回标准 Navigation Timing Level 2 数据
• TTFB = responseStart - requestStart
• 白屏时间 ≈ domLoading - fetchStart
• 可交互时间 = domInteractive - fetchStart
• 调用时机必须是 window.addEventListener('load', ...) 或 document.readyState === 'complete' 后，否则返回空数组

定位慢资源与加载瓶颈

图片卡顿、JS 阻塞、第三方脚本拖后腿？靠 getEntriesByType('resource') 深挖：

• 每个 entry 包含 startTime、responseEnd、duration、initiatorType（script/img/css）
• 过滤出 duration > 1000 的资源，重点排查
• 跨域资源若未加 crossorigin 属性，duration 会归零，需前端统一补全
• 结合 nextHopProtocol 判断是否用了 HTTP/2 或 QUIC，辅助网络优化决策

标记业务关键路径（User Timing）

框架加载完没？搜索框渲染好了吗？首屏卡片数据拉取多久？这些业务指标不能只靠猜：

• 在逻辑起点调用 performance.mark('search-start')
• 在终点调用 performance.mark('search-end')
• 再用 performance.measure('search-total', 'search-start', 'search-end') 计算耗时
• 后续可通过 getEntriesByType('measure') 批量提取，上报服务端做聚合分析
• 标记名建议带命名空间，如 'ui-header-render'，避免冲突