First Input Delay (FID)

Philip Walton

浏览器支持

• <ph type="x-smartling-placeholder"></ph> 76 个
• <ph type="x-smartling-placeholder"></ph> 79 个
• <ph type="x-smartling-placeholder"></ph> 89
• <ph type="x-smartling-placeholder"></ph> 倍

来源

<ph type="x-smartling-placeholder">

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

我们都知道给人留下良好的第一印象有多么重要。请务必注意 结识新朋友时，这也很重要 。

在网络上，良好的第一印象会影响不同的人 成为忠实用户，或者离开网站，一再回访。问题是， 怎样才能给人留下良好的印象，以及如何衡量 有哪些好处？

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

虽然使用 Web API 很难衡量用户对网站设计的喜爱程度， 但测量其速度和响应能力却不尽如人意！

用户对您网站加载速度的第一印象 First Contentful Paint (FCP)。但您的网站对像素的绘制速度 只是整个故事的一部分。同样重要的是 用户尝试与这些像素互动的网站！

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

什么是 FID？

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

什么是良好的 FID 得分？

为了提供良好的用户体验，网站应努力为用户提供首次输入 延迟不超过 100 毫秒。为了确保您能在 因此比较理想的阈值是指标的第 75 个百分位 网页加载时间细分为移动设备和桌面设备。

<ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder"></ph>

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

FID 详情

作为开发者，在编写响应事件的代码时，我们通常会假定代码 将在事件发生后立即运行。但作为用户 我们都经常遇到相反的情况： 都曾尝试与它互动 情况。

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

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

请参考以下典型网页加载时间轴：

上面的图表显示了一个正在发出几个网络请求的网页 资源（最可能是 CSS 和 JS 文件）， 下载完毕时，系统会在主线程中进行处理。

这会导致主线程暂时处于忙碌状态， 以浅灰色显示 任务 。

较长的首次输入延迟通常发生在 First Contentful Paint) (FCP) 和可交互时间 (TTI)，因为该网页 已渲染部分内容，但尚不能可靠交互。举例说明 FCP 和 TTI 已添加至时间表：

您可能已经注意到，我们设置了一段 FCP 和 TTI 之间） 在这段时间内与网页进行了互动（例如点击链接）， 收到点击与主线程能够执行 。

设想一下，如果用户尝试与网页附近的网页互动，会发生什么情况？ 用时最长的任务开始：

由于当浏览器在运行任务的过程中进行输入， 它必须等到任务完成后才能响应输入。通过 该页面上此用户的 FID 值就是它必须等待的时间。

注意 ：在此示例中，用户恰好在主线程最繁忙时段开始时与页面进行了互动。如果用户在不久前（即空闲期间）与网页进行了互动，那么浏览器可能会立即做出响应。这种输入延迟差异凸显了在报告指标时查看 FID 值分布的重要性。您可以在下文中分析和报告 FID 数据的部分了解详情。

如果互动没有事件监听器怎么办？

FID 测量收到输入事件与主事件处理 下一个空闲线程。也就是说，即使在事件发生后，系统仍会衡量 FID， 监听器。这是因为许多用户互动 不需要事件监听器，但确实需要主线程在 投放。

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

• 文本字段、复选框和单选按钮（<input>、<textarea>）
• 选择下拉菜单（<select> 个）
• 链接（<a> 个）

为什么只考虑第一种情况？

虽然任何输入延迟都会导致糟糕的用户体验，但我们主要 建议测量 First Input Delay，原因如下：

• First Input Delay 将是用户对您网站的第一印象 响应速度和第一印象至关重要，这对于塑造 对网站质量和可靠性的印象。
• 当今网络上最大的互动问题发生在网页中 加载。因此，我们认为最初的侧重点在于增加网站的首个 最大限度地提升 网络的交互性
• 有关网站应如何解决首次输入延迟偏高问题的建议解决方案 （代码拆分、预先加载的 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，您可以使用事件计时 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 条目报告给父帧以进行汇总。

开发者不必记住所有这些细微差别，只需使用 web-vitals JavaScript 库 衡量 FID，从而为您处理这些差异（如果可能，请注意 iframe 问题未涵盖在内）：

import {onFID} from 'web-vitals';

// Measure and log FID as soon as it's available.
onFID(console.log);

您可以参阅 onFID() ，获取如何在 JavaScript 中衡量 FID 的完整示例。

注意 ：在某些情况下（例如跨源 iframe），您无法在 JavaScript 中衡量 FID。如需了解详情，请参阅 web-vitals 库的限制部分。

分析和报告 FID 数据

由于 FID 值的预期差异，因此在生成 对于 FID，您会考虑值的分布情况，并重点关注更高的百分位数。

虽然 百分位数 Core Web Vitals 阈值为第 75 位，特别是对于 FID，我们仍坚决 建议关注第 95-99 个百分位 用户在使用您的网站时首次获得的体验尤其糟糕。它 会显示哪些方面需要改进。

即使您按设备类别或类型对报告进行细分，情况也是如此。对于 例如，如果您为桌面设备和移动设备生成单独的报告， 应处于桌面用户的第 95–99 个百分位； 而您在移动设备上最关心的 FID 值应为 95–99 百分比的移动用户。

如何改善 FID

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

更新日志

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

为帮助您应对此问题，对这些指标的实现或定义所做的所有更改都会显示在此更新日志中。

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