fid衡量用户首次交互后浏览器主线程排队响应的延迟，非用户反应时间；仅现场采集，需web-vitals sdk在尽早监听first-input，优化关键在于减少首屏长任务阻塞。
FID 不是“页面加载完没”，也不是“用户点得快不快”，它只反映主线程有没有空——空，就立刻响应；被占满，用户点下去就得排队等。优化 FID 的本质，就是减少首屏 JS 执行对主线程的长期垄断。
为什么 Lighthouse 测不出真实的 FID
Lighthouse 是实验室工具，它不模拟真实用户点击时机，也不触发真实输入事件队列。它跑完页面加载后直接报告 FID: 0 或 Not applicable，这毫无参考价值。
- 真实 FID 只能通过现场（field）采集：必须用
web-vitalsSDK 在用户真实会话中监听first-input -
getFID()必须尽早执行——建议内联在里，或至少加async；放在window.onload后就可能错过首个点击 - CrUX 数据按 origin 聚合，看不到具体 URL 或用户路径；要定位问题页面，得靠 RUM 工具上报 + 自定义维度打标
哪些 JS 行为最拖累 FID
FID 高 = 主线程在用户点下那一刻正忙得不可开交。典型长任务包括：
- 同步解析/编译超大 JS bundle（比如未 code-split 的 1.2MB
app.js） - 首屏渲染时遍历上千 DOM 节点并批量
setAttribute或classList.add - 第三方脚本（如广告 SDK、A/B 测试工具）在
DOMContentLoaded前注入并立即执行 200ms+ 的同步逻辑 - 框架初始化（如 React
hydrateRoot或 VuecreateApp().mount()）前做了大量计算或数据预处理
注意：setTimeout 或 Promise.then 不会直接拉高 FID，但若它们触发的回调本身是长任务，仍会阻塞后续输入。
怎么验证优化是否生效
别只看平均值——FID 是取所有首次交互中最大的排队延迟，所以单次长任务就能让整页 FID 拉爆。
- 用
web-vitalsSDK 上报时，务必记录metric.attribution.eventType和metric.attribution.target，确认卡顿是否集中在某个按钮或表单 - Chrome DevTools → Performance 面板录制用户操作：过滤出
Input Delay事件，看它前面紧挨着哪个长任务（Task或Script Evaluation） - 对比优化前后 CrUX 的 75th percentile FID 值（不是平均值），Google Search Console 的「Core Web Vitals」报告里可查
一个常被忽略的点：FID 已于 2024 年 3 月被 INP 正式取代，但 CrUX 和许多 RUM 工具仍在上报 FID；如果你还在优化 FID，本质上是在为 INP 做前置准备——因为 INP 关注的是“最差交互”，而降低首屏长任务正是两者共通的解法。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
