优化首次输入延迟（FID）：提升交互响应速度的方法

首次输入延迟（FID）指从用户首次与页面交互，到页面做出响应之间的时间。它衡量响应性，曾是 Google 用于评估页面体验的三项核心网页指标（Core Web Vitals）之一。自 2024 年 3 月 12 日起，FID 已被“与下一次绘制交互”（Interaction to Next Paint，INP）取代。

计入统计的交互示例包括：

• 点击链接或按钮。
• 在空白字段中输入文本。
• 选择下拉菜单。
• 勾选复选框。

滚动、缩放等事件则不计入其中。

下面说明 FID 应达到多快，以及如何改进。

什么样的 FID 值算良好？

良好的 FID 值应低于 100 毫秒，并基于 Chrome 用户体验报告（CrUX）数据，即来自实际访问网站的 Chrome 用户、且已选择分享这些信息的数据。若要判定为良好，需有 75% 的交互在 100 毫秒以内响应。

页面会被归入以下某一档：

• 良好：<=100 毫秒
• 需要改进：>100 毫秒且 <=300 毫秒
• 较差：>300 毫秒

FID 数据

截至 2023 年 4 月，95.3% 的网站处于良好 FID 档位，这是整个网站的均值。如前所述，需有 75% 的交互在 100 毫秒以内响应，才会显示为良好。

多数网站上的多数页面都能通过 FID 这项 CWV 检查。我并不认为它是衡量响应性的最佳方法，Google 已在 2024 年 3 月用“与下一次绘制交互”（INP）取代 FID。INP 不再只看首次输入，而是考察用户所有交互的延迟。

在开展核心网页指标研究时，我们发现几乎无人需要担心桌面端连接下的 FID，移动端需要担心的人也极少。

很少有网站需要为 FID 担心，即便在较慢的连接下也是如此，因为其大多数页面都能通过。

研究中的页面级数据同样说明了这一点。对多数页面而言，FID 似乎都不成问题。

如何测量 FID

唯一重要的 FID 数字来自 Chrome 用户体验报告（CrUX），即选择分享数据的真实 Chrome 用户数据。

这称为实测数据（field data），最能反映真实环境下、不同网络条件、设备、缓存等情况下的 FID 表现，也是 Google 在核心网页指标方面实际衡量网站的依据。

为获得一致、可重复的测试，还有实验室数据（lab data），即在相同条件下测试所得。FID 无法通过实验室测试获得，因为测试工具不会点击任何东西。不过可以用总阻塞时间（Total Blocking Time，TBT）作为替代指标；改进被阻塞的流程，同样会改善 FID。

测量单个 URL 的 FID

Pagespeed Insights 会拉取页面级的实测数据，这类数据在 CrUX 数据集中无法查询。它还会提供源站（origin）数据，便于把页面性能与整个网站对比，并基于 Google Lighthouse 运行实验室测试，给出 TBT。

测量多个 URL 或整个网站的 FID

可以在 Google Search Console 中获取 CrUX 数据，它被划分为良好、需要改进和较差几档。

点击其中某个问题，可看到受影响页面的分组明细。这些分组由数值相近、很可能使用同一模板的页面组成；在模板中修改一次，该分组内的所有页面都会随之修复。

若想大规模获取实验室数据和实测数据，唯一途径是 PageSpeed Insights API。可以用 Ahrefs 的 Site Audit 轻松连接它，获得详细呈现性能的报告。对于拥有 Ahrefs Webmaster Tools（AWT）账户的已验证网站，这项功能免费。

用 Site Audit 免费检查你的 CWV（含 FID）

请注意，所显示的核心网页指标数据取决于设置过程中为抓取选择的 user-agent。若从移动端抓取，就会从 API 获得移动端的 CWV 数值。

免费工具：为最多 10 个页面或网站检查桌面端和移动端的 CWV 及 Lighthouse 指标

这是另一个免费工具，可一次检查最多 10 个页面或网站，看看你与竞争对手相比如何。

设置：

• 将 Google PageSpeed Insights API 密钥填入指定输入框（此处可了解如何生成 API 密钥）。
• 添加要分析的 URL（每行一个）。

运行分析：

• 点击“Check CWV”按钮开始获取指标，进度指示器会显示请求状态。

查看结果：

• 结果会显示在分类清晰的评分卡中：
• 每项指标以颜色编码表示性能：

核心网页指标批量检查器（Core Web Vitals Bulk Checker）

这是一个示例输出，展示速度评分卡的外观。它可以作为独立工具使用：网站速度测试。

是什么导致了延迟？

JavaScript 会争夺主线程。主线程只有一个，而 JavaScript 都想在它上面运行任务。

JavaScript 必须在主线程上轮流运行。如同一台只有一个灶眼的炉子，一次只能做一道菜，手头却有好几道菜。

当某个任务正在运行时，页面无法响应用户输入，这就是可感知的延迟。任务越长，用户感受到的延迟越久。

任务之间的间隙，是页面切换到用户输入任务、响应用户操作的时机。在较慢的设备上情况更糟，因为 JavaScript 处理更耗时，延迟也更长。

如何改进 FID

在 PageSpeed Insights 中可以看到 TBT 标签页，其中列出与主线程被阻塞相关的问题，这些正是改进 FID 需要解决的问题。

大多数页面都能通过 FID 检查。不过若需针对 FID 优化，可着手的项目并不多：

1. 减少 JavaScript 的数量

如果能减少运行的 JavaScript 数量，就优先这么做，重点关注页面加载早期的 JavaScript。若此前优化不足，加载早期可能塞满大量 JavaScript，全都想在那一个主线程上运行。

2. 尽可能延后加载 JavaScript

任何不需要马上用到的 JavaScript 都应延后加载，主要有 defer 和 async 两种属性，可加到 script 标签上。

通常，脚本在下载和执行期间会阻塞解析器。async 让解析与下载同时进行，但脚本执行期间仍会阻塞解析。defer 在下载期间不会阻塞解析，只在 HTML 解析完成后才执行。

该用哪一个？对于希望更早加载或有依赖关系的内容，我倾向于用 async。

例如，我倾向于在分析（analytics）标签上使用 async，以便记录到更多用户。对于稍后才需要、或没有依赖关系的内容，更宜用 defer。添加这些属性很容易。

示例：

普通：

[['Text', '<script src="https://www.domain.com/file.js"></script>']]

Async：

[['Text', '<script src="https://www.domain.com/file.js" async></script>']]

Defer：

[['Text', '<script src="https://www.domain.com/file.js" defer></script>']]

3. 拆分长任务

另一种选择是把 JavaScript 拆分，使其运行时间更短，即把延迟用户输入响应的长任务拆成阻塞时间更短的小任务。这通过代码分割（code splitting）实现，把任务拆成更小的块。

4. 使用 Web Worker

也可以把一部分 JavaScript 移到 service worker 中。前面提到 JavaScript 会在浏览器中争夺唯一的主线程，这是一种变通办法，提供了另一个运行位置。

缓存方面会有一些权衡。此外 service worker 无法访问 DOM，因此无法更新或更改页面。若打算把 JavaScript 移到 service worker，确实需要一位熟悉相关机制的开发人员。

5. 使用预渲染或服务端渲染（SSR）

如果使用 JavaScript 框架，页面加载需要大量 JavaScript，其在浏览器中处理可能耗时，从而造成延迟。使用预渲染或 SSR，可以把这一负担从浏览器转移到服务器。

结语

尽管 FID 已在 2024 年 3 月被 INP 取代，改进 FID 仍然值得。为改进 TBT 和 FID 所做的许多工作，同样能改进 INP。

如有疑问，可以在 Twitter 上给我留言。