fid 必须用 performanceobserver 异步监听，因其唯一暴露浏览器调度层首次输入延迟；tti 则需结合主线程空闲观察与交互验证，异步逻辑易破坏连续5秒无长任务条件。

直接用 PerformanceObserver 监听 first-input 类型，是获取真实 FID 的唯一可靠方式；而 TTI 无法靠异步打点直接测得，必须结合主线程空闲观察与交互验证——异步逻辑（如 Promise 链、微任务、懒加载）恰恰是拖慢 TTI 的关键因素。

为什么 FID 必须用 PerformanceObserver 异步监听

FID 不是“用户点击到 JS 执行”的时间差，而是从输入事件触发（如 pointerdown）到浏览器主线程真正开始处理该事件之间的延迟。这个延迟发生在浏览器调度层，普通 JS 无法观测。

• 手动监听 click 或 keydown 只能拿到事件分发时刻，漏掉排队等待时间
• 用 Date.now() 或 performance.now() 在事件回调开头打点，会把 JS 执行耗时也混进去，结果偏大且不可比
• PerformanceObserver 是浏览器唯一暴露该底层调度延迟的标准化接口，且只在首次有效输入时触发一次

如何正确注册 observer 并捕获 FID

注册必须早、缓冲必须开、判断必须准：

• 脚本需内联或加 async，避免等 DOMContentLoaded，否则可能错过首屏前的点击
• 务必设置 buffered: true，否则页面加载中发生的首次输入会被丢弃
• 只过滤 entry.entryType === 'first-input'，不要依赖 entry.name（旧版 Chrome 可能伪造）
• entry.duration 就是标准 FID 值（毫秒），无需再减去任何时间戳

异步逻辑如何干扰 TTI 判定

TTI（Time to Interactive）定义为：页面完成首次渲染后，主线程连续 5 秒无长任务（>50ms），且能响应用户输入的最早时间点。异步操作常在背后悄悄破坏这一条件：

• 第三方 SDK（如 Sentry、埋点库）常在 DOMContentLoaded 后异步加载并执行，触发长任务
• React/Vue 组件内 useEffect 或 mounted 中发起的 API 请求 + 数据处理，可能产生微任务链阻塞空闲窗口
• 图片懒加载、字体加载、Web Worker 初始化等虽不占主线程，但其回调常触发 DOM 更新或样式重排，间接延长“可交互”确认周期

用 performance.mark 辅助定位异步瓶颈

mark 本身不测 TTI，但可作为锚点串联分析：

• 在所有关键事件监听器绑定完毕后，立即 performance.mark('ready-for-input')
• 启动 requestIdleCallback 循环，每 100ms 检查是否连续 50 次未被长任务打断
• 达标后调用 performance.mark('tti-confirmed')，再立刻模拟一次 click 验证 handler 是否触发
• 用 performance.measure('tti', 'navigationStart', 'tti-confirmed') 记录耗时，上报时带上设备类型与分位数