我们都知道给用户留下好的第一印象有多重要。这对于结交新朋友至关重要，在打造 Web 体验时也非常重要。
在网络上，好的第一印象决定着用户成为忠实用户，还是离开而不再回访。问题是，怎样才能给用户留下好印象？如何衡量您可能会给用户留下什么样的印象？
在网络上，第一印象可能有多种形式：我们对网站设计和视觉吸引力的第一印象，以及对网站速度和响应速度的第一印象。
虽然很难通过 Web API 来衡量用户对网站设计的喜爱程度，但衡量网站的速度和响应速度却不是这样！
用户对网站加载速度的第一印象可通过 First Contentful Paint (FCP) 衡量。不过，您的网站能够以多快的速度将像素绘制到屏幕上，这只是问题的一部分。同样重要的是，当用户尝试与这些像素互动时，您的网站响应速度也同样重要！
首次输入延迟 (FID) 指标有助于衡量用户对您网站的互动性和响应速度的第一印象。
什么是 FID？
FID 衡量的是从用户首次与网页互动（即，点击链接、点按按钮或使用由 JavaScript 提供支持的自定义控件）到浏览器实际能够开始处理事件处理脚本以响应相应互动的时间。
FID 得分良好是多少？
为了提供良好的用户体验，网站应努力将 First Input Delay 控制在 100 毫秒以内。为确保大多数用户都达到此目标，最好衡量一下网页加载的第 75 个百分位（按移动设备和桌面设备细分）。
FID 详情
作为编写响应事件的代码的开发者，我们通常假设我们的代码会在事件发生后立即运行。但作为用户，我们都经常会遇到相反的情况：我们在手机上加载了一个网页，尝试与该网页互动，然后在没有任何反应时感到沮丧。
一般来说，之所以会发生输入延迟（也称为输入延迟）是因为浏览器的主线程正忙于执行其他操作，因此还不能响应用户。发生这种情况的一个常见原因是，浏览器正忙于解析和执行应用加载的大型 JavaScript 文件。在此过程中，浏览器无法运行任何事件监听器，因为它正在加载的 JavaScript 可能会指示它执行其他操作。
请考虑以下典型网页加载时间轴：
上图展示的网页正在对资源（很可能是 CSS 和 JS 文件）发出几个网络请求，这些资源下载完成后，会在主线程上处理。
这会导致主线程短暂处于忙碌状态，以米黄色的任务块表示。
首次输入延迟通常发生在首次内容绘制 (FCP) 和可交互时间 (TTI) 之间，因为网页已渲染部分内容，尚不能可靠地互动。为说明发生这种情况的原因，我们在时间轴中添加了 FCP 和 TTI：
您可能已经注意到，FCP 和 TTI 之间要经历相当长的时间（包括三项长任务），如果用户在此期间尝试与网页互动（例如，点击链接），从收到点击到主线程能够响应会有延迟。
不妨设想一下，如果用户尝试与页面互动，在耗时最长的任务快要开始执行时，会发生什么情况：
由于输入发生在浏览器运行任务的过程中，浏览器必须等到任务完成后才能响应输入。而必须等待的时间就是此页面上此用户的 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。
野外工具
衡量 JavaScript 中的 FID
如需在 JavaScript 中衡量 FID，您可以使用 Event Timing API。以下示例展示了如何创建用于监听 first-input 条目并将其记录到控制台的 PerformanceObserver：
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});
在上面的示例中，通过获取条目的 startTime 和 processingStart 时间戳之间的增量来衡量 first-input 条目的延迟值。在大多数情况下，这将是 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);
如需查看如何在 JavaScript 中衡量 FID 的完整示例，请参阅 onFID() 的源代码。
分析和报告 FID 数据
由于 FID 值存在预期方差，因此在报告 FID 时，请务必查看值的分布并专注于较高的百分位。
虽然所有核心网页指标阈值的百分位选择都是第 75 百分位，但就 FID 而言，我们仍强烈建议查看第 95 到 99 百分位，因为这些百分位数对应于用户在您网站上遇到的特别糟糕的第一体验。该报告会显示需要最大改进的方面。
即使您按设备类别或类型对报告进行细分，情况也是如此。例如，如果您针对桌面设备和移动设备分别生成了报告，那么在桌面设备上您最关注的 FID 值应该是桌面用户的第 95 到 99 百分位，而您在移动设备中最关心的 FID 值应该是移动用户的第 95 到 99 百分位。
如何改进 FID
您可以参阅有关优化 FID 的完整指南，了解改进此指标的技巧。
更新日志
有时，bug 会在用于衡量指标的 API 中发现，有时会在指标本身的定义中发现。因此，有时必须进行更改，这些更改可能会以改进或回归的形式显示在内部报告和信息中心内。
为了帮助您管理这些变更，这些指标的实现或定义方面的所有更改都会显示在此更新日志中。
如果您对这些指标有反馈意见，可以在 web-vitals-feedback Google 网上论坛中提供。