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')记录耗时，上报时带上设备类型与分位数
