First Input Delay (FID) vs. Interaction to Next Paint (INP) – Vercel

As of March 2024, Interaction to Next Paint (INP) will replace the First Input Delay (FID) as a new Core Web Vital.
自 2024 年 3 月起，Interaction to Next Paint (INP) 将取代首次输入延迟 (FID)，成为新的 Core Web Vital。

First Input Delay is a web performance metric that measures the time between a user's very first interaction with a web page and the time when the browser's main thread is able to start processing that interaction event.
首次输入延迟是一种 Web 性能指标，用于测量用户首次与网页交互与浏览器主线程能够开始处理该交互事件之间的时间。

When a user interacts with a web page, an event is added to a queue to be processed by the browser's main thread. However, if the main thread is already busy doing other tasks like parsing HTML, executing JavaScript, or handling other event listeners, the new event has to wait in the queue.
当用户与网页交互时，事件会被添加到队列中，由浏览器的主线程处理。但是，如果主线程已经忙于执行其他任务，例如解析 HTML、执行 JavaScript 或处理其他事件侦听器，则新事件必须在队列中等待。

The FID metric captures the duration of this waiting time, which tells us how long it takes for the browser to respond to the user's first input while the main thread is busy.
FID 指标捕获此等待时间的持续时间，它告诉我们在主线程繁忙时浏览器响应用户的第一个输入需要多长时间。

However, the First Input Delay (FID) metric has some shortcomings:
然而，首次输入延迟 (FID) 指标有一些缺点：

• FID only considers the delay of the first input event, ignoring subsequent interactions that may also be slow or even slower.
  FID仅考虑第一个输入事件的延迟，忽略后续也可能很慢甚至更慢的交互。
• Other factors can contribute to a longer visual feedback delay between user interactions, which FID doesn't measure. This includes the time it takes to process event handlers and recalculate the layout before providing visual feedback to the user.
  其他因素可能会导致用户交互之间的视觉反馈延迟较长，而 FID 无法测量这一点。这包括在向用户提供视觉反馈之前处理事件处理程序和重新计算布局所需的时间。

---

To address these limitations, the Interaction to Next Paint (INP) metric will replace First Input Delay.
为了解决这些限制，下次绘制交互 (INP) 指标将取代首次输入延迟。

While FID only measured the input delay, which is the time between user input and the browser starting to execute the event handler, INP measures:
FID 仅测量输入延迟，即用户输入和浏览器开始执行事件处理程序之间的时间，而 INP 测量：

• Input Delay: the time between user interaction and the time the browser is able to process the event, similar to FID.
  输入延迟：用户交互之间的时间和浏览器能够处理事件的时间，类似于 FID。
• Processing Delay: the time it takes the browser to process the event handlers
  处理延迟：浏览器处理事件处理程序所花费的时间
• Presentational Delay: the time it takes the browser to recalculate the layout and paint the pixels to the screen.
  呈现延迟：浏览器重新计算布局并将像素绘制到屏幕上所需的时间。

Additionally, whereas FID only measured the very first user interaction, the INP score is measured when the user leaves the page by aggregating all interactions the user made with the page throughout the page’s lifetime and returning the worst-measured score.
此外，FID 仅测量第一次用户交互，而 INP 分数是在用户离开页面时通过聚合用户在页面生命周期内与页面进行的所有交互并返回最差测量分数来测量的。

With INP, we no longer have to focus solely on optimizing event queuing times and main thread availability, as was the case with FID. Now, it is also crucial to address the entire lifecycle of a user interaction. This includes processing event handlers, recalculating layouts, and painting updates to the screen, all of which are critical components of the INP metric.
借助 INP，我们不再需要像 FID 那样仅仅关注优化事件排队时间和主线程可用性。现在，解决用户交互的整个生命周期也至关重要。这包括处理事件处理程序、重新计算布局以及在屏幕上绘制更新，所有这些都是 INP 指标的关键组成部分。

---

Optimizing your INP score
优化您的 INP 分数

For FID, the primary goal was to reduce the time between a user's initial interaction and when the browser's main thread starts processing it. This typically involved optimizing JavaScript execution times, breaking down long tasks, and ensuring the main thread remains as free as possible during user interactions.
对于 FID，主要目标是减少用户初始交互与浏览器主线程开始处理交互之间的时间。这通常涉及优化 JavaScript 执行时间、分解长任务以及确保主线程在用户交互期间保持尽可能空闲。

However, with INP, we need to consider a broader range of performance factors.
然而，对于 INP，我们需要考虑更广泛的性能因素。

Processing Delay 处理延迟

The processing delay emphasizes the importance of not only starting the event handler quickly but also executing it efficiently. We can optimize the processing delay by:
处理延迟强调了不仅快速启动事件处理程序而且高效执行它的重要性。我们可以通过以下方式优化处理延迟：

• Profiling code and identifying performance bottlenecks.
  分析代码并识别性能瓶颈。
• Using techniques like debounce or throttle for frequently firing event handlers.
  使用 debounce 或 throttle 等技术来频繁触发事件处理程序。
• Code splitting and tree shaking to reduce unnecessary JavaScript. Load only what is necessary, when it is necessary.
  代码分割和树摇动以减少不必要的 JavaScript。在必要时仅加载必要的内容。
• Breaking down long JavaScript tasks into smaller chunks. The longer a task takes on the main thread, the longer it will block user interactions.
  将长 JavaScript 任务分解为更小的块。任务在主线程上花费的时间越长，阻塞用户交互的时间就越长。

Presentational Delay 表现迟缓

After processing an event, the browser may need to recalculate styles, reflow layouts, and repaint the screen. We can optimize the presentational delay by:
处理事件后，浏览器可能需要重新计算样式、重排布局并重新绘制屏幕。我们可以通过以下方式优化呈现延迟：

• Using the will-change property judiciously to inform the browser about properties and elements likely to be animated.
  明智地使用 will-change 属性来通知浏览器有关可能动画的属性和元素。
• Opting for transform and opacity changes for animations as they are less likely to cause layout recalculations.
  选择 transform 和 opacity 会更改动画，因为它们不太可能导致布局重新计算。
• Using properties like content-visibility to render and update content only when necessary.
  仅在必要时使用 content-visibility 等属性来渲染和更新内容。
• Reducing forced synchronous layouts. Avoid reading layout properties immediately after writing them, as this can trigger the browser to synchronize and recalculate styles and layouts.
  减少强制同步布局。避免在写入布局属性后立即读取布局属性，因为这可能会触发浏览器同步并重新计算样式和布局。
• Using web forkers for non-urgent and non-UI tasks. By offloading these tasks to background threads, you can keep the main thread free and responsive to user interactions.
  使用 Web forker 执行非紧急和非 UI 任务。通过将这些任务卸载到后台线程，您可以保持主线程空闲并响应用户交互。

Event Handling 事件处理

Event handlers should be executed efficiently and effectively. We can do this by:
事件处理程序应该高效且有效地执行。我们可以通过以下方式做到这一点：

• Deferring non-critical events until the main thread is less busy.
  将非关键事件推迟到主线程不太忙时。
• Using passive event listeners for events like scroll and touch. This informs the browser that the event listener will not prevent a scroll or touch event, allowing the browser to continue smooth scrolling without waiting for the listener.
  对 scroll 和 touch 等事件使用被动事件侦听器。这通知浏览器事件侦听器不会阻止滚动或触摸事件，从而允许浏览器继续平滑滚动而无需等待侦听器。
• Delegating events by, instead of attaching event listeners to individual elements, attaching them to a common parent and using event properties to determine which child element was interacted with. This reduces the number of active event listeners and potential slowdowns.
  通过将事件侦听器附加到公共父元素并使用事件属性来确定与哪个子元素进行交互来委派事件，而不是将事件侦听器附加到各个元素。这减少了活动事件侦听器的数量和潜在的速度减慢。

---

Measuring your INP score 测量您的 INP 分数

To maintain an optimized and responsive website, Real User Monitoring (RUM) tools can be used to regularly collect performance data from actual users, which is crucial for measuring INP.
为了维护优化且响应迅速的网站，可以使用真实用户监控 (RUM) 工具定期收集实际用户的性能数据，这对于衡量 INP 至关重要。

While the metric is not yet officially stable, we can already measure INP using tools like:
虽然该指标尚未正式稳定，但我们已经可以使用以下工具来衡量 INP：

• Vercel Speed Insights Vercel 速度见解
• PageSpeed Insights PageSpeed 见解
• Lighthouse's Timespan feature
  Lighthouse 的时间跨度功能

---

The INP metric provides a broader perspective by recognizing the significance of not just the time it takes for the browser to start processing an event, but also the total time needed to respond to the user's interactions visually.
INP 指标不仅认识到浏览器开始处理事件所需时间的重要性，而且认识到以视觉方式响应用户交互所需的总时间，从而提供了更广泛的视角。

Optimizing for INP will not only result in more responsive and seamless interactions but also greatly enhance the overall user experience.
针对 INP 进行优化不仅会带来更快的响应速度和无缝交互，还会大大增强整体用户体验。

If you're using Next.js, using React 18's concurrent features can also help improve your INP score. Learn more in this blog post.
如果您使用 Next.js，使用 React 18 的并发功能也可以帮助提高您的 INP 分数。在此博文中了解更多信息。