Performance API 是可编程的性能探针，用于从加载、渲染、执行三层面定位影响用户体验的环节：通过 navigation 数据拆解 TTFB、DNS/TCP、白屏、可交互时间；筛选慢且关键的第三方脚本并验证长任务；用 User Timing 标记业务节点；以 PerformanceObserver 持续监听 LCP、FID、CLS 等核心指标。
Performance API 不是用来“看一眼就完事”的工具，它是一套可编程的性能探针，能从加载、渲染、执行三个层面定位真实影响用户体验的环节。关键不在数据多，而在怎么筛、怎么比、怎么归因。
抓准导航全过程，看清瓶颈在哪一环
页面加载慢，到底是网络卡、服务器慢，还是前端解析拖后腿？用 performance.getEntriesByType('navigation') 拿到首个导航记录，再按阶段拆解耗时：
- TTFB（首字节时间）=
responseStart - requestStart，大于 500ms 说明服务端或网络有问题 - DNS + TCP 耗时 =
connectEnd - domainLookupStart，持续偏高需检查 DNS 配置或 CDN 节点 - 白屏时间 =
domContentLoadedEventStart - fetchStart，反映 HTML 解析和同步脚本执行效率 - 可交互时间 =
domInteractive - fetchStart，比 DOM Ready 更贴近用户真实操作起点
揪出拖后腿的资源，尤其是第三方脚本
不是所有慢资源都一样重要。重点关注那些既慢、又大、又在关键路径上执行的第三方脚本：
- 筛选条件：type 是
script，且name域名不等于当前document.domain - 触发警报：duration > 200ms 或 transferSize > 100KB
- 叠加渲染时机：检查其
executeStart是否落在 LCP 前 300ms 内——此时执行极易导致内容绘制延迟 - 补充验证：结合
performance.getEntriesByType('longtask')，确认该脚本是否构成主线程阻塞（executeEnd − executeStart > 50ms）
标记业务关键节点，把技术指标和用户行为对齐
光有浏览器指标不够，得知道“搜索按钮点击后多久出结果”“商品页首图何时真正可见”。这时用 User Timing API 打点：
- 在关键逻辑入口打标记：
performance.mark('search-start') - 在结果渲染完成时再打一个：
performance.mark('search-done') - 用
performance.measure('search-duration', 'search-start', 'search-done')自动生成耗时条目 - 后续可通过
performance.getEntriesByName('search-duration')提取并上报，形成可追踪的业务性能闭环
监听核心体验指标，让监控跟上用户真实感受
LCP、FID、CLS 这些指标不能只靠 Lighthouse 测一次，要用 PerformanceObserver 在真实用户会话中持续捕获：
- 注册观察器，监听
largest-contentful-paint、first-input、layout-shift - 每个 entry 返回的
startTime和value直接对应指标数值（如 LCP 的毫秒值、CLS 的小数） - 务必在页面 load 后再上报，避免干扰主流程；对单页应用，需在路由切换后重新监听新页面的 LCP
- 注意：Chrome 120+ 已弃用
performance.timing，所有计算必须基于getEntriesByType或PerformanceObserver
