First Input Delay (FID)

Philip Walton

Browser Support

• 76
• 79
• 89
• 26.2

Source

警告： First Input Delay (FID) 不再是核心 Web 指标，已被 Interaction to Next Paint (INP) 指标取代。因此，对 FID 的支持已于 2024 年 9 月 9 日结束。您现在应重点关注 INP。

我们都知道，留下良好的第一印象非常重要。无论是结识新朋友，还是在网上打造体验，第一印象都至关重要。

在网上，良好的第一印象可能会让用户成为忠实用户，也可能会让用户离开并永不回头。问题是，如何留下良好的第一印象？您又该如何衡量自己可能会给用户留下什么样的印象？

在网上，第一印象可以有很多不同的形式，例如网站的设计和视觉吸引力，以及网站的速度和响应能力。

虽然很难使用 Web API 衡量用户对网站设计的喜爱程度，但衡量网站的速度和响应能力却并非难事！

用户对网站加载速度的第一印象可以通过 First Contentful Paint (FCP)来衡量。但网站将像素绘制到屏幕的速度只是故事的一部分。同样重要的是，当用户尝试与这些像素互动时，网站的响应速度如何！

First Input Delay (FID) 指标有助于衡量用户对网站互动性和响应能力的第一印象。

什么是 FID？

FID 衡量的是从用户首次与网页互动（即点击链接、点按按钮或使用由 JavaScript 提供支持的自定义控件）到浏览器实际能够开始处理事件处理程序以响应此次互动的时间。

FID 得分多少才算良好？

为了提供良好的用户体验，网站应尽力将 First Input Delay 控制在 100 毫秒 以内。为确保大多数用户的体验能够达到此目标值，建议以网页加载量的第 75 百分位 作为衡量阈值，并分别按移动端和桌面端进行细分。

注意： 如需详细了解此建议背后的研究和方法，请参阅：定义 Core Web Vitals 指标的阈值

FID 详解

作为编写代码来响应事件的开发者，我们通常会假设我们的代码会在事件发生后立即运行。但作为用户，我们经常会遇到相反的情况：我们在手机上加载了一个网页，尝试与之互动，但却发现什么也没发生，这令人沮丧。

一般来说，输入延迟（也称为输入延迟时间）的发生是因为浏览器的主线程正忙于执行其他操作，因此无法（还无法）响应用户。 这种情况的一个常见原因是，浏览器正忙于解析和执行应用加载的大型 JavaScript 文件。在执行此操作时，它无法运行任何事件监听器，因为其加载的 JavaScript 可能会指示它执行其他操作。

FID 仅衡量事件处理中的“延迟”。它不衡量事件处理本身的总时长，也不衡量浏览器在运行事件处理程序后更新界面的时间。虽然此时间确实会影响用户体验，但将其纳入 FID 会激励开发者异步响应事件，这会提高指标，但可能会使体验变差。如需了解详情，请参阅下文，了解为何仅考虑输入延迟。

请考虑以下典型网页加载的时序：

上面的可视化图表显示了一个网页，该网页正在发出几个资源网络请求（很可能是 CSS 和 JS 文件），并且在这些资源下载完成后，它们会在主线程上进行处理。

这会导致主线程暂时处于繁忙状态，这由 米色 任务 块表示。

较长的首次输入延迟通常发生在 First Contentful Paint (FCP) 和 Time to Interactive (TTI) 之间，因为网页已 呈现部分内容，但尚未可靠地实现互动。为了说明这种情况是如何发生的，FCP 和 TTI 已添加到时间轴中：

您可能已经注意到，FCP 和 TTI 之间有相当长的时间（包括三个长时间运行的 任务），如果用户在此期间尝试与网页 互动（例如，点击链接），那么从收到点击到主线程能够 响应之间会存在 延迟。

请考虑一下，如果用户尝试在最长任务开始时与网页互动，会发生什么情况：

由于输入发生在浏览器正在运行任务的过程中，因此浏览器必须等到任务完成才能响应输入。它必须等待的时间就是此用户在此网页上的 FID 值。

注意： 在此示例中，用户恰好在主线程最繁忙的时期开始时与网页互动。如果用户早一点（在空闲期间）与网页互动，浏览器就可以立即响应。输入延迟的这种差异突显了在报告指标时查看 FID 值分布的重要性。如需了解详情，请参阅下文有关分析和报告 FID 数据的部分。

如果互动没有事件监听器，会怎么样？

FID 衡量的是收到输入事件与主线程下次空闲之间的时间差。这意味着，即使未注册事件监听器，也会衡量 FID。 原因是，许多用户互动不需要事件监听器，但确实需要主线程处于空闲状态才能运行。

例如，以下所有 HTML 元素都需要等待主线程上正在进行的任务完成，然后才能响应用户互动：

• 文本字段、复选框和单选按钮 (<input>, <textarea>)
• 选择下拉列表 (<select>)
• 链接 (<a>)

为何仅考虑首次输入？

虽然任何输入的延迟都可能导致糟糕的用户体验，但我们主要建议衡量首次输入延迟，原因如下：

• 首次输入延迟将是用户对网站响应能力的第一印象，而第一印象对于塑造我们对网站质量和可靠性的整体印象至关重要。
• 我们今天在网上看到的最大互动性问题发生在网页加载期间。因此，我们认为，最初专注于改进网站的带来用户首次互动的…将对提升网络的整体可交互性产生最大的影响。
• 针对网站应如何解决首次输入延迟过高问题（代码拆分、预先加载较少的 JavaScript 等）的建议解决方案，不一定与解决网页加载后输入延迟缓慢问题的解决方案相同。通过将这些指标分开，我们将能够为 Web 开发者提供更具体的性能指南。

哪些事件会被计为首次输入？

FID 是一项指标，用于衡量网页在加载期间的响应能力。因此，它仅关注来自离散操作（如点击、点按和按键）的输入事件。

其他互动（如滚动和缩放）是连续操作，并且具有完全不同的性能限制（此外，浏览器通常能够通过在单独的线程上运行它们来隐藏其延迟）。

换句话说，FID 侧重于 RAIL 性能 模型中的 R（响应能力），而 滚动和缩放与 A（动画）更相关，其性能 质量应单独评估。

如果用户从不与您的网站互动，会怎么样？

并非所有用户每次访问您的网站时都会与之互动。并非所有互动都与 FID 相关（如上一部分所述）。此外，有些用户的首次互动时间不佳（主线程长时间处于繁忙状态），有些用户的首次互动时间良好（主线程完全处于空闲状态）。

这意味着，有些用户没有 FID 值，有些用户的 FID 值较低，有些用户的 FID 值可能较高。

您跟踪、报告和分析 FID 的方式可能与您可能习惯的其他指标有很大不同。下一部分将介绍如何以最佳方式执行此操作。

为何仅考虑输入延迟？

如上所述，FID 仅衡量事件处理中的“延迟”。它不衡量事件处理本身的总时长，也不衡量浏览器在运行事件处理程序后更新界面的时间。

虽然此时间对用户很重要，并且确实会影响体验，但它不包含在此指标中，因为这样做可能会激励开发者添加实际上会使体验变差的变通方案，也就是说，他们可能会将事件处理脚本逻辑封装在异步回调中（通过 setTimeout() 或 requestAnimationFrame()），以便将其与事件关联的任务分开。 结果是指标得分有所提高，但用户感知到的响应速度却变慢了。

不过，虽然 FID 仅衡量事件延迟的“延迟”部分，但想要跟踪更多事件生命周期的开发者 可以使用 Event Timing API 来实现此目的。如需了解详情，请参阅custom metrics指南。

如何衡量 FID

FID 是一项只能在实测 环境中衡量的指标，因为它需要真实 用户与您的网页互动。您可以使用以下工具衡量 FID。

**注意：** FID 需要真实用户，因此无法在实验室中衡量。 不过，Total Blocking Time (TBT) 指标可在实验室中衡量，与实测环境中的 FID 相关性良好，并且还可以捕获影响互动性的问题。在实验室中改进 TBT 的优化也应改进用户的 FID。

实测工具

• Chrome 用户体验报告
• PageSpeed Insights
• Search Console（Core Web Vitals 报告）
• web-vitals JavaScript 库

在 JavaScript 中衡量 FID

如需在 JavaScript 中衡量 FID，您可以使用 Event Timing API。以下示例展示了如何 创建 PerformanceObserver ，该观察器会监听 first-input 条目并将其记录到控制台：

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const delay = entry.processingStart - entry.startTime;
    console.log('FID candidate:', delay, entry);
  }
}).observe({type: 'first-input', buffered: true});

警告： 此代码展示了如何将 first-input 条目记录到控制台并计算其延迟。不过，在 JavaScript 中衡量 FID 更加复杂。详情如下：

在上面的示例中，first-input 条目的延迟值是通过计算条目的 startTime 和 processingStart 时间戳之间的时间差来衡量的。在大多数情况下，这将是 FID 值；不过，并非所有 first-input 条目都可用于衡量 FID。

以下部分列出了 API 报告的内容与指标计算方式之间的差异。

指标与 API 之间的差异

• API 将为在后台标签页中加载的网页调度 first-input 条目，但在计算 FID 时应忽略这些网页。
• 如果网页在首次输入发生之前已在后台运行，API 也会调度 first-input 条目，但在计算 FID 时也应忽略这些网页（只有当网页始终在前台运行时，才会考虑输入）。
• 当网页从 往返缓存恢复时，API 不会报告 first-input 条目，但应 在这些情况下衡量 FID，因为用户会将这些情况视为不同的网页 访问。
• API 不会报告在 iframe 中发生的输入，但指标会报告，因为它们是网页用户体验的一部分。这可能会 显示为 CrUX 和 RUM 之间的差异。 如需正确衡量 FID，您应考虑这些输入。子框架可以使用 API 将其 first-input 条目报告给父框架以进行汇总。

注意： 在某些情况下（例如跨源 iframe），无法在 JavaScript 中衡量 FID。

分析和报告 FID 数据

由于 FID 值存在预期差异，因此在报告 FID 时，务必查看值的分布情况，并重点关注较高的百分位。

虽然所有核心 Web 指标阈值的百分位选择都是第 75 百分位，但对于 FID，我们仍然强烈建议查看第 95 百分位到第 99 百分位，因为这些百分位将对应于用户在您的网站上遇到的特别糟糕的首次体验。它将向您展示最需要改进的方面。

即使您按设备类别或类型细分报告，也是如此。例如，如果您为桌面设备和移动设备分别运行报告，那么您最关心的桌面设备上的 FID 值应该是桌面设备用户的第 95 百分位到第 99 百分位，而您最关心的移动设备上的 FID 值应该是移动设备用户的第 95 百分位到第 99 百分位。

如何改进 FID

我们提供了一份关于优化 FID 的完整指南，可指导您了解改进此指标的技术。

更新日志

有时，用于衡量指标的 API 中会发现 bug，有时指标的定义本身也会发现 bug。因此，有时必须进行更改，而这些更改可能会在您的内部报告和信息中心中显示为改进或回归。

为了帮助您管理此问题，这些指标的实现或定义的所有更改都将在此更新日志中显示。

如果您对这些指标有反馈，可以在 web-vitals-feedback Google 群组 中提供。