必须监听"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] 就是安全的。
- 必须在页面早期（如
内或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 数据天然具备可比性与准确性，不需要再做任何校正或插值。其他优化（如减少主线程阻塞、预加载交互资源）都该基于这个真实数据来判断优先级。
