Performance API 用于精准测量用户行为发生时的性能表现，核心是关联操作与浏览器执行时间以判断体验流畅性；它通过捕获FID、手动打点测响应、监听长任务与布局偏移、结构化标记上报来实现。
Performance API 不是用来“追踪用户行为”（比如点击了哪个按钮、看了哪段文字），而是用来精准测量用户行为发生时的**性能表现**——特别是响应是否及时、页面是否卡顿。它的核心价值在于把用户操作和浏览器底层执行时间对应起来，从而判断体验是否流畅。
捕获首次交互延迟（FID）
FID 是衡量响应性的黄金指标，指用户第一次点击、触摸或按键后，浏览器主线程从忙到空闲并开始处理该事件的时间差。它真实反映“用户觉得卡不卡”：
- 必须在页面加载早期注册
PerformanceObserver，监听first-input类型条目，否则可能漏掉首屏交互 - FID 超过 100ms 就属于可感知卡顿，建议触发轻量干预（如禁用非关键动画）
- 注意：FID 只发生一次，无法反映后续交互质量，需配合其他指标持续监控
持续测量交互响应时间
仅靠 FID 不够，真实场景中用户会反复操作。可通过手动打点方式评估每次交互的实际响应耗时：
- 在事件监听器开头调用
performance.now()记录起始时间 - 在关键逻辑执行完毕、UI 更新完成后再调用
performance.now()计算差值 - 例如：点击按钮 → 发起请求 → 渲染新内容 → 打点结束，全程耗时即为该次交互响应时间
- 建议设定阈值（如 >150ms）并统计短时间窗口内的超标频次，作为降级依据
关联主线程压力与布局稳定性
单看响应时间还不够，要结合浏览器内部状态判断卡顿根源：
- 监听
longtask类型条目，识别阻塞主线程超过 50ms 的任务（如复杂计算、同步 DOM 操作） - 订阅
layout-shift来捕获意外的布局偏移，这类抖动常伴随交互卡顿出现 - 当连续几秒内同时出现多次长任务 + 高 FID 或布局偏移，基本可判定是渲染或 JS 执行瓶颈
上报与归因分析
采集到的数据需要结构化上报，才能用于问题定位和优化验证：
- 使用
performance.mark()标记关键节点（如 “click-start”、“render-finish”） - 用
performance.measure()关联标记，生成可读性更强的阶段耗时（如 “button-click-to-render”） - 上报时附带上下文：设备类型、网络条件（
navigator.connection.effectiveType）、页面路径、是否已降级 - 避免全量上报，可对慢交互样本做 100% 上报，快交互按比例采样
