First Input Delay (FID)

Philip Walton

浏览器支持

• 76
• 79
• 89
• x

来源

警告：First Input Delay (FID) 不再是 Core Web Vitals，已被互动到下一次绘制 (INP) 指标取代。因此，我们于 2024 年 9 月 9 日终止了对 FID 的支持。现在，您应专注于 INP。

我们都知道给人留下良好的第一印象有多么重要。这在结识新朋友时很重要，在构建 Web 体验时也很重要。

在网络上，良好的第一印象决定着用户会成为忠实用户，还是离开而不再回访。问题是，什么样的印象是好的？您如何衡量自己可能会给用户留下什么样的印象？

在网络上，第一印象可以有很多不同的形式，我们对网站的设计和视觉吸引力有第一印象，对其速度和响应能力也有第一印象。

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

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

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

什么是 FID？

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

什么是良好的 FID 得分？

为了提供良好的用户体验，网站应尽量将首次输入延迟时间控制在 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。如需了解详情，请参阅自定义指标指南。

如何衡量 FID

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

注意：FID 需要真实用户，因此无法在实验室中衡量。不过，总阻塞时间 (TBT) 指标可通过实验室衡量，与实际使用中的 FID 密切相关，并且可捕获影响互动性的问题。在实验室中用于改善 TBT 的优化措施应该也会改善用户的 FID。

实地工具

• Chrome 用户体验报告
• PageSpeed Insights
• Search Console（“核心网页指标”报告）
• 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 时，请务必查看值的分布情况，并重点关注较高的百分位数。

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

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

如何改善 FID

我们提供了有关优化 FID 的完整指南，可引导您了解如何改进此指标。

更新日志

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

为帮助您管理这些指标，我们会在此更新日志中显示对这些指标的实现或定义所做的所有更改。

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