如何通过 PerformanceObserver 采集页面的“首次输入延迟（FID）”以优化交互响应

作者：袖梨 2026-07-26

必须监听"first-input"类型，因为只有它能准确提供首个用户输入事件的startTime与processingStart之差即FID值；监听"event"无法识别首次输入且无处理延迟数据，"navigation"则完全无关。

直接用 PerformanceObserver 监听 "first-input" 类型，是目前唯一能准确获取真实 FID 的方式；其他基于 Event.timeStamp 或手动打点的方法，都会因事件队列延迟、主线程阻塞或时间戳归一化问题导致结果偏低或丢失。

为什么必须监听 `"first-input"` 而不是 `"event"` 或 `"navigation"`

浏览器只对真正触发用户交互响应的首个输入事件（如 click、keydown、pointerdown）生成 "first-input" 条目，并在内部完成从事件分发到主线程开始执行回调之间的时间差计算。监听 "event" 会捕获所有事件，但无法区分“是否为首次”且不包含处理延迟；监听 "navigation" 完全无关，它只记录加载阶段数据。

"first-input" 条目自带 startTime（事件触发时刻）和 processingStart（主线程真正开始处理的时刻），二者之差即为 FID 值
该条目仅触发一次，且保证在用户首次可交互后、页面未卸载前被投递
若页面从未收到有效输入（如纯展示页），PerformanceObserver 不会触发回调，无需额外兜底逻辑

如何正确注册并提取 FID 值

注册时需指定 type: "first-input"，并在回调中遍历 entries 取第一个 entry——虽然理论上只有一条，但规范允许批量投递，不能假设 entries[0] 就是安全的。

必须在页面早期（如 <head> 内或 document.readyState === "loading" 时）注册，否则可能错过首屏后的首次输入
回调中应立即读取 entry.duration，它等价于 entry.processingStart - entry.startTime，是标准 FID 数值
不要依赖 entry.name 判断事件类型，它固定为 "first-input"；具体交互类型看 entry.entryType（始终为 "first-input"）或通过 entry.interactionId 关联后续事件（高级用法）

const observer = new PerformanceObserver((list) => {  for (const entry of list.getEntries()) {    if (entry.entryType === "first-input") {      const fid = entry.duration; // 这就是真实的 FID 值（毫秒）      console.log("FID:", fid);      // 上报逻辑      break; // 只取第一个，后续忽略    }  }});observer.observe({ type: "first-input", buffered: true });

常见误操作与兼容性注意点

看似简单的 API，实际落地时容易栽在几个细节上：注册时机、buffered 参数、移动端输入差异、以及 SPA 场景下的重复注册。

buffered: true 必须开启——否则页面加载完成前发生的首次输入事件会被丢弃（尤其对快速点击首屏按钮的用户）
不要在每次路由跳转后重新 observe() 同一 type，会导致重复回调；应在应用初始化时注册一次，长期保持活跃
部分安卓 WebView 或旧版 iOS Safari（"first-input"，需降级 fallback：监听 click/touchstart 并用 performance.now() 打点，但要明确标注“估算值”
FID 是单页指标，不跨导航；微前端场景下，子应用若独立管理交互，需各自注册自己的 PerformanceObserver

最关键的其实是注册时机和 buffered: true 的组合——漏掉这个，等于在用户第一次点击时就放弃了测量权；而一旦注册成功，FID 数据天然具备可比性与准确性，不需要再做任何校正或插值。其他优化（如减少主线程阻塞、预加载交互资源）都该基于这个真实数据来判断优先级。