首次输入延迟（FID）：测的是什么，为什么被 INP 取代

什么是首次输入延迟？

首次输入延迟（First Input Delay，FID）衡量的是：访客头一次和页面互动（点击、轻触或按键）到浏览器能开始执行响应代码之间的时间。它反映页面因为主线程在忙（通常是 JavaScript）而不理会用户的时间有多长。

FID 从 2020 年起是 Google 三项核心网页指标之一。2024 年 3 月 12 日，Google 用 Interaction to Next Paint（INP） 取代了它，FID 不再是核心网页指标。旧报表、旧文章和一些工具里还会看到它。

FID 阈值

Google 的阈值，按真实页面加载的第 75 百分位评估：

FID 测了什么，漏了什么

一次互动分三段。以点击「加入购物车」为例的时间线（示例）：

所以 FID 只覆盖了头一次互动的等待部分。一个页面可能 FID 很好，但之后的每次点击都很慢，或者事件处理本身就要几百毫秒。INP 弥补了这两点：它考虑页面上所有互动，并计算到下一帧绘制为止的完整时长。

为什么 FID 被取代

• 只看头一次互动。 很多慢互动发生在页面加载完之后。
• 只看延迟。 事件处理和渲染慢都看不到。
• 太容易达标。 在 Chrome 的现场数据里，绝大多数网站在手机上 FID 都已经是「良好」，它已经分不出快站和慢站。

相关的实验室指标

FID 需要真实用户来互动，只能在现场测。Lighthouse 这类实验室工具用 总阻塞时间（TBT） 和「最大潜在 FID」（加载期间最长的任务）作为近似，两者都衡量主线程被长任务阻塞了多久。

怎么降低输入延迟

FID 高的原因，和 INP 里输入延迟那一段一样：

1. 拆分长任务。 把 JavaScript 工作切成每段不超过 50 毫秒，中间把主线程让出来。
2. 少发 JavaScript。 删掉没用的代码，拆分打包，延后非关键脚本。
3. 延后第三方脚本（标签、组件、A/B 测试脚本），等页面可交互之后再加载。
4. 避免加载时做重活，比如给用户还看不到的大组件做水合。
5. 能用 Web Worker 的，把工作挪出主线程。

在 TapCub 里

TapCub 的性能报表用真实访问测量核心网页指标，报告 INP，以及 LCP、CLS、首字节时间和首次内容绘制，可以看 P75、P95、中位数或平均值。它不报告 FID，因为 FID 已经被 INP 取代。如果要和旧的 FID 基线对比，INP 里输入延迟那一部分是最接近的对应。见核心网页指标和检查核心网页指标。

参考资料

• web.dev. First Input Delay (FID).
• web.dev. Interaction to Next Paint becomes a Core Web Vital on March 12.
• MDN Web Docs. First input delay.