Interaction to Next Paint (INP)

Jeremy Wagner

Barry Pollard

发布时间：2022 年 5 月 6 日；最后更新时间：2025 年 9 月 9 日

Chrome 使用情况数据显示，用户在网页上花费的时间有 90% 都发生在网页加载之后。因此，仔细衡量网页生命周期内的响应速度非常重要。这就是 INP 指标评估的内容。

良好的响应能力意味着网页能够快速响应互动。当网页响应互动时，浏览器会在下一个绘制的帧中呈现视觉反馈。视觉反馈可告知您，例如，您添加到在线购物车中的商品是否确实已添加、移动导航菜单是否已打开、登录表单的内容是否正在由服务器进行身份验证，等等。

有些互动自然会比其他互动花费更长时间，但对于特别复杂的互动，务必要快速呈现一些初始视觉反馈，告知用户正在发生某些事情。浏览器将绘制的下一个帧是执行此操作的最早时机。

因此，INP 的目的不是衡量互动的所有最终效果（例如来自其他异步操作的网络提取和界面更新），而是衡量下一次绘制被阻塞的时间。如果延迟提供视觉反馈，用户可能会认为网页的响应速度不够快，而 INP 的开发正是为了帮助开发者衡量用户体验的这一方面。

在以下视频中，右侧的示例会立即提供视觉反馈，表明手风琴正在打开。左侧的示例展示了响应速度慢的情况，以及这种情况如何导致用户体验不佳。

本指南介绍了 INP 的运作方式、如何衡量 INP，并提供了可用于改进 INP 的资源。

什么是 INP？

INP 指标通过观测网页在用户访问期间发生的所有点击、点按和键盘互动的延迟时间，评估网页对用户互动的总体响应情况。最终 INP 值是观测到的最长互动时间，离群值会被忽略。

互动是指在同一逻辑用户手势期间触发的一组事件处理程序。例如，在触摸屏设备上进行的“点按”互动包含多个事件，例如 pointerup、pointerdown 和 click。互动可以由 JavaScript、CSS、内置浏览器控件（例如表单元素）或它们的组合来驱动。

互动的延迟时间是指驱动互动的一组事件处理程序中最长的单个时长，从用户开始互动时到浏览器下一次能够绘制帧时为止。在极少数情况下，可能没有要绘制的帧，但当浏览器能够绘制帧时，互动会结束。

INP 得分多少才算良好？

很难为响应性指标贴上“好”或“差”等标签。一方面，您希望鼓励采用优先考虑良好响应能力的应用开发实践。另一方面，您必须考虑到用户所用设备的性能差异很大，以便设定可实现的发展预期。

为确保您提供响应速度良好的用户体验，一个不错的衡量阈值是实地记录的网页加载时间的第 75 个百分位数，按移动设备和桌面设备进行细分：

• 如果 INP 低于或等于 200 毫秒，则表示网页具有良好的响应速度。
• 如果 INP 高于 200 毫秒且低于或等于 500 毫秒，则表示网页的响应速度需要改进。
• 如果 INP 高于 500 毫秒，则表示网页的响应速度较慢。

互动中包含哪些内容？

互动性的主要驱动因素通常是 JavaScript，不过浏览器也通过不由 JavaScript 提供支持的控件（例如复选框、单选按钮和由 CSS 提供支持的控件）提供互动性。

由于 INP 的用途，因此仅会观察以下互动类型：

• 使用鼠标点击。
• 点按配备触摸屏的设备。
• 按实体键盘或屏幕键盘上的某个键。

互动发生在主文档或嵌入在文档中的 iframe 中，例如点击嵌入视频中的“播放”按钮。最终用户不会知道 iframe 中包含哪些内容，因此需要测量 iframe 中的 INP，以评估顶级页面的用户体验。由于 JavaScript Web API 无法访问 iframe 的内容，因此这可能会导致 CrUX 和 RUM 之间出现差异

互动可以包含多个事件。例如，按键操作包括 keydown、keypress 和 keyup 事件。点按互动包含 pointerup 和 pointerdown 事件。互动中持续时间最长的事件会影响互动的总延迟时间。

如图所示，INP 的处理时长包括相应帧内的所有事件处理程序回调。这样一来，输入延迟就是处理互动的所有回调之前的时间，处理时长就是执行所有回调的时间，而呈现延迟就是执行回调之后到在用户屏幕上呈现帧的时间。

当用户离开网页时，系统会计算该网页的 INP。最终得到一个代表网页在整个生命周期内的总体响应能力的单一值。INP 值较低表示网页能够可靠地响应用户输入。

INP 与 First Input Delay (FID) 有何不同？

INP 是 First Input Delay (FID) 的后继指标。虽然两者都是响应性指标，但 FID 仅衡量网页上首次互动的输入延迟。INP 通过观察网页上的所有互动来改进 FID，从输入延迟开始，到运行事件处理程序所花费的时间，最后直到浏览器绘制下一个帧。

这些差异意味着 INP 和 FID 是不同类型的响应速度指标。FID 是一项旨在评估网页给用户的初步印象的加载响应速度指标，而 INP 是一项更可靠的总体响应速度指标，无论互动发生在网页生命周期的哪个阶段，它都能准确反映网页的响应速度。

如果未报告任何 INP 值，该怎么办？

网页可能不会返回任何 INP 值。造成这种情况的原因有很多，包括：

• 网页已加载，但用户从未点击、点按或按键盘上的键。
• 网页已加载，但用户通过未衡量的手势（例如滚动或将鼠标悬停在元素上）与网页互动。
• 网页正被机器人（例如搜索抓取工具或无头浏览器）访问，但该机器人未编写脚本来与网页互动。

如何衡量 INP

INP 既可以在实际环境中衡量，也可以在实验环境中衡量，前提是您能够模拟真实的用户互动。

在实地

理想情况下，您应从实地数据着手优化 INP。在最佳情况下，实时用户监控 (RUM) 提供的实测数据不仅会显示网页的 INP 值，还会提供相关背景数据，突出显示导致 INP 值的具体互动、互动是在网页加载期间还是之后发生、互动类型（点击、按键或点按），以及其他有价值的时间数据，帮助您确定互动的哪个部分影响了响应速度。

如果您的网站符合纳入 Chrome 用户体验报告 (CrUX) 的条件，您就可以通过 PageSpeed Insights 中的 CrUX 快速获取 INP 实测数据（以及其他核心网页指标）。您至少可以获得网站的源级 INP 概览，但在某些情况下，您还可以获得网址级数据。

不过，虽然 CrUX 可以告知您是否存在问题，但无法告知您问题的原因。RUM 解决方案可帮助您详细了解存在响应速度问题的网页、用户或用户互动。能够将 INP 归因于单个互动，可避免猜测和浪费精力。

实验室

理想情况下，当现场数据表明某个网页的互动缓慢时，您就可以开始在实验室中进行测试。借助现场数据，在实验室中重现问题互动将变得更加简单。

不过，您完全有可能没有实地数据。虽然 INP 可以在某些实验室工具中进行衡量，但实验室测试期间网页的最终 INP 值将取决于在衡量期间执行的互动。用户行为可能难以预测且变化很大，这意味着您在实验室中进行的测试可能无法像实地数据那样发现问题互动。此外，某些实验性工具不会报告网页的 INP，因为它们仅观察网页的加载情况，而不进行任何互动。在这种情况下，总阻塞时间 (TBT) 可能是 INP 的合理代理指标，但它本身并不能替代 INP。

虽然在评估网页的 INP 方面，实验室工具存在一些限制，但有一些策略可用于在实验室中重现缓慢的互动。这些策略包括遵循常见用户流程并测试沿途的互动，以及在网页加载时（此时主线程通常最繁忙）与网页互动，以便在用户体验的关键部分识别缓慢的互动。

在 JavaScript 中衡量 INP

如需在 JavaScript 中衡量 INP，您需要衡量所有互动的事件计时，然后在网页卸载时取所有这些互动的第 98 百分位数。您可以参考 web vitals JavaScript 库源代码，其中包含有关如何计算 INP 的参考实现。

在大多数情况下，网页卸载时的当前 INP 值是该网页的最终 INP 值，但也有一些重要的例外情况，如下一部分所述。web vitals JavaScript 库会在 Web API 的限制范围内尽可能多地考虑这些因素。

指标与 API 之间的差异

• 默认情况下，低于 104 毫秒的 event 条目不会使用性能观察器进行报告。在注册性能观察器时，可以使用 durationThreshold 参数更改此默认值，但即使这样，该参数的最小值也为 16 毫秒。因此，建议您同时观察 first-input 条目，该条目也是一个 Event Timing 条目，但即使其时长小于 durationThreshold，也保证可以观察到。这有助于确保有互动的网页始终会报告某个 INP 值。
• 从技术上讲，要完美计算百分位数，需要将所有样本都保留在内存中，这可能会产生高昂的费用。不过，您可以通过仅保留一个包含最差 N 次互动的小列表来近似计算百分位数，尤其是像 p98 这样非常高的百分位数。10 是一个常见的选择。
• 如果网页是从往返缓存中恢复的，则其 INP 值应重置为零，因为用户会将此视为一次不同的网页访问。
• 该 API 不会针对 iframe 内发生的互动报告 event 条目，但该指标会报告，因为这些互动是网页用户体验的一部分。这可能会导致 CrUX 和 RUM 之间出现差异。为了正确衡量 INP，您应该考虑这些因素。子框架可以使用该 API 将其 event-timing 条目报告给父框架。

除了上述例外情况之外，INP 还存在一些额外的复杂性，因为它会衡量网页的整个生命周期：

• 用户可能会将标签页保持打开状态很长时间，例如几天、几周或几个月。事实上，用户可能永远不会关闭某个标签页。
• 在移动操作系统上，浏览器通常不会为后台标签页运行页面卸载回调，因此很难报告“最终”值。

为了处理此类情况，除了卸载页面时（visibilitychange 事件涵盖这两种情况）之外，还应在任何时候报告 INP。接收此数据的分析系统随后需要在后端计算最终的 INP 值。

开发者无需自行记忆和处理所有这些情况，而是可以使用 web-vitals JavaScript 库来衡量 INP，该库会考虑上述所有情况（iframe 情况除外）：

import {onINP} from 'web-vitals';

// Measure and log INP in all situations
// where it needs to be reported.
onINP(console.log);

如何改进 INP

我们提供了一系列有关优化 INP 的指南，可引导您完成以下流程：识别实际应用中的缓慢互动，并使用实验数据来帮助您找出原因并进行优化。

更新日志

有时，我们会发现用于衡量指标的 API 中存在 bug，有时也会发现指标本身的定义存在 bug。因此，有时必须进行更改，而这些更改可能会在您的内部报告和信息中心中显示为改进或回归。

为方便您管理这些指标，我们会在更改日志中显示这些指标的实现或定义的所有更改。

如果您对这些指标有反馈，请在 web-vitals-feedback Google 群组中提供。

知识测验