首次输入延迟 （FID）：优化完整指南
首次输入延迟 （FID） 是一项核心 Web 重要指标， 用于衡量用户首次与页面交互与浏览器可以开始处理该交互之间的延迟。它是加载速度的关键指标，影响 Google 的排名标准。 从 2024 年 3 月开始，FID 将过渡到更全面的指标 INP。
TL;DR 如何改善首次输入延迟？
- 最大限度地减少 JavaScript 执行时间。
- 在 50 毫秒内将长任务分解成更小的异步块。
- 实现代码拆分以按需延迟加载非关键 JavaScript
- 使用 Web Worker 在单独的后台线程上运行 JavaScript 任务
- 优化 API 调用和数据库查询的服务器响应时间
文章目录
什么是首次输入延迟 （FID）？
首次输入延迟是一个真实用户的 Web 性能指标，它跟踪从用户进入网页后首次与网页交互到浏览器可以开始处理该交互（当浏览器的主线程空闲时）之间的时间。
这两个事件之间的时间称为输入延迟（也称为输入延迟）。
换句话说，FID 反映了用户交互 （当单击或点击链接或按钮等内容时） 与浏览器响应你的动作并开始处理它的时间之间的延迟。
想象一下，访问一家在线商店并期望当场打开给定的元素。但是，单击的超链接可能不会立即响应。从技术上讲，这是因为浏览器的主线程正在处理不同的请求。
由 FID 衡量的计为用户输入的事件必须是离散的（有限）。连续类型的用户交互，如缩放或滚动页面，无法使用此指标准确衡量。这是因为它们通常不在浏览器的主线程上运行，并且具有不同的约束。
FID 仅衡量首次用户交互
FID 是关于第一印象的，使其成为用户体验指标。 用户首次与页面交互是他们体验和感知 Web 性能的基础。
此外，浏览器主线程的大部分阻塞发生在网页生命周期的最初时刻——那是加载关键资源的时候。FID 是一个指标，可帮你解决这个问题并确保加载这些关键资源不会让网站感觉笨拙和无响应。
FID 测量输入延迟，而不是处理
由于该交互而对网页的实际处理或更新不是由 FID 衡量的。这是因为通过将事件处理程序与与事件关联的任务分开，开发人员可以很容易地玩弄 FID。
为什么会发生输入延迟？
当页面元素（如图像或脚本）在没有用户请求的情况下加载时，会出现输入延迟。
根据 Google 的说法 ，长时间输入延迟背后的原因之一是 JavaScript 执行。具体而言，它适用于浏览器在运行任何事件侦听器之前必须执行的大型 JavaScript 文件。
为什么？因为正在加载的 JavaScript 代码可以改变浏览器的后续作。
当浏览器等待确定后续步骤时，它可能会使网站感觉无响应，从而导致较长的输入延迟。感觉浏览器陷入了交通拥堵，可以通过最小化 JavaScript 文件来简化。它可以减少浏览器注册事件所需的时间。
输入延迟因用户而异
First Input Delay 分数对网站的每位访客都是唯一的。一些访问者可能更容易分心并停止浏览页面，直到他们可以快速与内容交互。
虽然个人与网站的互动得分不同，但并非所有访客的行为都被认为与得分相关。 这就是为什么 Google 明白并非所有访问者都在一次访问中与网站互动是正常的。
First Input Delay 与 Time to Interactive 相同吗？
交互时间 （TTI） 衡量页面完全交互所需的时间，而首次输入延迟 （FID） 跟踪页面完全交互之前的用户输入。
当页面上已呈现有价值的内容时（由 First Contentful Paint 测量），为大多数页面元素注册事件处理程序，并在 50 毫秒内处理用户交互，则注册交互时间。
同时，First Input Delay 可以跟踪，例如，当用户单击在为大多数页面元素注册事件处理程序之前出现的链接时。 与 Time to Interactive 不同，First Input Delay 允许捕获那些早期的关键交互。
为什么首次输入延迟 （FID） 对 SEO 很重要？
- 首次输入延迟是最令人兴奋的 Web 性能指标之一，因为它纯粹是一个真实用户指标 。它不能在实验室测试中模拟，因为它需要测量真实的用户输入。 FID 是关于真实用户进入页面时的体验。
- 作为真实用户指标，监控和优化非常有用，因为它定义了网站的用户体验。
- First Input Delay 现在是 Google 的官方排名因素。 First Input Delay 是跟踪网站响应能力的指标，而 CLS 跟踪视觉稳定性，而 LCP 跟踪加载速度。谷歌在 2021 年 6 月上线时将 Core Web Vitals 作为其排名算法的一部分 。
换句话说，有很多理由专注于网站上的首次输入延迟优化。
想更深入地了解 FID、CLS 和 LCP 吗？在我们的 Core Web Vitals 终极指南中了解有关它们的更多信息 。
什么是好的 FID 分数？
研究表明，100 毫秒的延迟被认为是由相关源引起的。0.1 秒大约是让用户感觉到系统正在立即做出反应的极限。
由于这些原因，最好尝试将 FID 保持在 100 毫秒以下。
以下是 Google 在 PageSpeed Insights 中为 FID 设置的阈值：
- FID 为 100 毫秒或更短被认为是好的，
- 100-300ms 之间的 FID 需要改进，
- 超过 300 毫秒的 FID 被认为是差的。
请记住，浏览器仍然需要运行与用户输入关联的任务，而 FID 不会测量该任务。因此，在某些情况下，您的 FID 可能低于 100 毫秒，但页面可能仍然感觉有点无响应。
如何提高 First Input Delay 分数？
如果对 FID 分数不满意，通常表明需要改进 JavaScript 或 CSS 的使用。
以下是如何继续进行 First Input Delay 优化。
优化 CSS 代码
对于 CSS 文件，需要尽快下载和解析它们，以便浏览器可以呈现页面的布局。因此， 减少 CSS 对首次输入延迟影响的选项是有限的 。例如缩小和压缩文件或删除未使用的 CSS 代码。
优化 JavaScript 代码
JavaScript 任务通常是输入延迟较长的罪魁祸首。长时间阻塞浏览器的主线程，他们不允许它处理用户输入。
这是你可以开启 JavaScript SEO 服务的时候 。
此外，以下是一些可用于最大限度地减少主线程被 JavaScript 执行阻塞的时间的策略：
创建小型异步任务
长任务会阻塞主线程，不允许它处理用户输入。如果将它们分解为较小的任务，则可以在它们之间处理用户输入。尽量将任务保持在 50 毫秒以下以确保安全。
生成服务器端内容
旨在最大限度地减少需要在客户端后处理的数据量。这减少了浏览器为呈现页面而必须完成的工作量。
探索第三方代码的按需加载
第三方代码（例如标签或 analytics）通常会不必要地阻塞主线程。虽然有时需要在一开始就加载分析以确保正确跟踪整个访问，但可能会在页面上发现不需要立即运行的第三方代码。优先加载认为首先为用户提供最大价值的内容。
使用 Web Worker
可以将一些主线程工作委托给 Web Worker，以减少主线程上的工作负载。Web worker 允许委托一些 JavaScript 代码在 worker 线程上运行，这意味着主线程的工作量更少，输入延迟更少。
延迟未使用的 JavaScript
使用 async 或 defer， 以便仅在需要时执行 JavaScript。如果使用的是现代 JS，请将 ES6 模块配置为按需加载。
最小化未使用的 polyfill
当用户使用较旧的浏览器时，需要 Polyfills。开发人员使用它们来构建具有现代 JavaScript 的网站，并且仍然向不支持某些现代功能的浏览器提供所有功能。
确保不需要 polyfills 时不运行它们。使用 module/nomodule 交付单独的 bundles。
闲置直到紧急
Idle until urgent 是 Google 的 Philip Walton 构思的一种代码评估策略。
此策略从两种最流行的代码评估方法（ 预先评估和延迟评估 ）中汲取元素 。
预先评估意味着所有代码都会立即运行。这种方法会导致页面加载很长时间，直到它完全交互式，但随后可以顺利运行而不会出现任何问题。
惰性评估是相反的方法——代码只在需要时运行。虽然它有它的好处并且可能对某些网站有用，但惰性评估意味着一旦需要运行代码，就有可能出现输入延迟。
Idle until urgent 利用这两种方法的最佳方面来提供一种智能的方式来评估代码，因此输入延迟最小。
Idle until emergency 允许在空闲期间运行代码，并尽可能充分利用主线程。同时， 它保证立即运行急需的代码。
如何修复输入延迟？
当浏览器响应用户与网站的交互（例如单击按钮或链接）的时间过长时，长输入延迟（输入延迟）是一个问题。要解决此问题，可以使用 HTML 属性来控制脚本的下载方式 （重新排序脚本文件并优化代码中的图像）或删除不必要的脚本。
如何衡量页面上的 FID？
First Input Delay 可以根据以下工具的字段数据进行分析：
通过 BigQuery（来源级别）或 CrUX API（来源级别和网址级别 ）发布的 Chrome 用户体验报告
PageSpeed 洞察
Search Console（“核心 Web 指标”报告）
Firebase 性能监控 。
如何使用 JavaScript 测量 FID？
还可以通过向页面添加 JavaScript 来衡量 FID。
有两种方法可以做到这一点：
使用 web-vitals JavaScript 库 。
将以下代码添加到页面，以便在控制台中打印 FID：
import {getFID} from 'web-vitals';
getFID(console.log);
手动添加 PerformanceObserver 以跟踪输入。
如果不想导入 web-vitals 库，还可以使用 Event Timing API 手动跟踪 FID。
此代码由 Philip Walton 在 web.dev 上发表的有关 FID 的文章中提供 。
let firstHiddenTime = document.visibilityState === 'hidden' ? 0 : Infinity;
document.addEventListener('visibilitychange', (event) => {
firstHiddenTime = Math.min(firstHiddenTime, event.timeStamp);
}, {once: true});
function sendToAnalytics(data) {
const body = JSON.stringify(data);
(navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
fetch('/analytics', {body, method: 'POST', keepalive: true});
}
try {
function onFirstInputEntry(entry, po) {
if (entry.startTime < firstHiddenTime) {
const fid = entry.processingStart - entry.startTime;
po.disconnect();
sendToAnalytics({fid});
}
}
const po = new PerformanceObserver((entryList, po) => {
entryList.getEntries().forEach((entry) => onFirstInputEntry(entry, po));
});
po.observe({
type: 'first-input',
buffered: true,
});
} catch (e) {
}
最大潜在首次输入延迟 – 最坏情况
首次输入延迟可能会因用户首次与页面交互的时间而有很大差异，因为浏览器的主线程在页面的整个生命周期中并不相同。因此，一些用户可能根本没有遇到延迟，而另一些用户可能会因此而强烈气馁，具体取决于他们首次与页面交互的时间。
因此， 监控页面的最大潜在首次输入延迟 （MPFID） 可能会有所帮助 。这是在注册 First Contentful Paint 后主线程上运行的最长任务的持续时间。
通过测量该任务的持续时间， 可以模拟用户与页面交互的潜在情况，就像此长任务开始时 ，并且必须等到任务完成才能处理输入。
优化 MPFID 涉及各种策略，这些策略可以减少最长任务的运行时间或将其分解为更小的块。
MPFID 是 Lighthouse 中包含的一个实验室指标。要查看它，请将页面的 Lighthouse 报告导出为 JSON 文件。
可以在 Lighthouse 中测量 FID 吗？
不可以，不能使用 Lighthouse 等实验室工具测量首次输入延迟。
它需要真实用户的交互才能注册输入事件。但是， 可以使用与 FID 密切相关的不同指标。
总阻塞时间 （TBT） 是可以在实验室中测量的指标示例。 如果提高 TBT，很可能会改善首次输入延迟。
TBT 测量主线程被阻止响应用户输入时，从 First Contentful Paint 到 Time To Interactive 之间的时间。
后续步骤
Nat H.
您好！我是Nat，imrnat的创始人。感谢您将宝贵的时间托付给我们，我希望您在这篇博文中找到了问题的答案。
如果您仍然想知道如何确切地推进您的自然增长，请查看我们的服务页面并安排一次免费的对话，我们将为您完成所有繁琐的工作。
希望能尽快与您交谈！
