First Input Delay(FID)
First Input Delay(FID)
是一种衡量网页性能的指标,它衡量的是用户与网页进行的第一个交互和浏览器主线程开始处理该交互事件之间的时间。
当用户与网页进行交互时,一个事件将被添加到队列中,等待浏览器的主线程进行处理。然而,如果主线程正在执行其他任务,如解析HTML
、执行JavaScript
或处理其他事件监听器,新事件就必须在队列中等待。
FID
指标捕捉了这种等待时间的持续时间,它告诉我们在主线程忙碌时浏览器响应用户的第一个输入需要多长时间。
然而,首次输入延迟(FID)
指标存在一些缺点:
FID
只考虑了第一个输入事件的延迟,忽略了可能也很慢甚至更慢的后续交互。- 其他因素可能导致用户交互之间的视觉反馈延迟更长,这是
FID
无法测量的。这包括处理事件处理程序和重新计算布局所需的时间,然后向用户提供视觉反馈。下一次绘制的交互(INP)
为了解决这些限制,下一次绘制的交互(INP)
指标将取代首次输入延迟。
虽然FID
只测量了输入延迟,即用户输入和浏览器开始执行事件处理程序之间的时间,但INP
测量了:
- 输入延迟:用户交互和浏览器能够处理事件之间的时间,类似于
FID
。 - 处理延迟:浏览器处理事件处理程序所需的时间
- 呈现延迟:浏览器重新计算布局并将像素绘制到屏幕上所需的时间。
此外,而FID
仅测量了用户的第一个交互,INP
分数是在用户离开页面时测量的,将用户在页面整个生命周期内所做的所有交互聚合起来,并返回最坏的测量分数。
由于页面生命周期内最坏的测量分数为120毫秒,因此总INP分数将为120
。
使用INP
,我们不再仅专注于优化事件排队时间和主线程可用性,就像FID
一样。现在,关键是要解决用户交互的整个生命周期。这包括处理事件处理程序、重新计算布局和将更新绘制到屏幕上,所有这些都是INP指标的关键组成部分。
优化您的INP分数
对于FID
,主要目标是减少用户初始交互和浏览器主线程开始处理它之间的时间。通常,这涉及优化JavaScript
执行时间、分解长任务,并确保主线程在用户交互期间尽可能保持空闲。
然而,使用INP
,我们需要考虑更广泛范围的性能因素。
处理延迟
处理延迟强调的重要性不仅是快速开始事件处理程序,还要有效地执行它。我们可以通过以下方式优化处理延迟:
- 对代码进行分析,并识别性能瓶颈。
- 对于频繁触发的事件处理程序,使用防抖或节流等技术。
- 使用代码拆分和树摇来减少不必要的
JavaScript
。只在必要时加载必要的内容。 - 将长的
JavaScript
任务拆分成较小的块。任务在主线程上花费的时间越长,阻塞用户交互的时间就越长。呈现延迟
在处理事件后,浏览器可能需要重新计算样式、重新布局和重绘屏幕。我们可以通过以下方式优化呈现延迟:
- 审慎地使用
will-change
属性,告知浏览器可能会进行动画处理的属性和元素。 - 选择使用变换和不透明度变化进行动画,因为它们不太可能导致布局重计算。
- 使用诸如
content-visibility
之类的属性,仅在必要时呈现和更新内容。 - 减少强制同步布局。避免在写入布局属性后立即读取它们,因为这可能会触发浏览器同步和重新计算样式和布局。
- 对于非紧急和非
UI
任务,使用Web forkers
。通过将这些任务卸载到后台线程,可以使主线程保持空闲并对用户交互做出响应。事件处理
事件处理程序应该高效且有效地执行。我们可以通过以下方式实现:
- 将非关键事件推迟到主线程较不繁忙时执行。
- 对于滚动和触摸等事件,使用被动事件监听器。这通知浏览器事件监听器不会阻止滚动或触摸事件,允许浏览器在不等待监听器的情况下继续平滑滚动。
- 通过将事件监听器附加到公共父级并使用事件属性确定与哪个子元素交互,而不是将事件监听器附加到单个元素,以减少活动事件监听器的数量和潜在的减速。
测量您的INP分数
为了保持优化和响应的网站,可以使用实际用户的实时用户监控(RUM)
工具定期收集性能数据,这对于测量INP至关重要。
虽然该指标尚未正式稳定,但我们已经可以使用诸如以下工具来测量INP
- Vercel Speed Insights
- PageSpeed Insights
- Lighthouse’s Timespan feature
INP
指标通过承认浏览器开始处理事件所需的时间以及对用户交互在视觉上做出响应所需的总时间的重要性,提供了更广泛的视角。
针对INP
进行优化不仅会导致更具响应性和无缝的交互,还会极大地增强整体用户体验。