Interaction to Next Paint (INP)

Jeremy Wagner

Barry Pollard

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

Browser Support

• 96
• 96
• 
• x

Source

注意：Interaction to Next Paint (INP) 是一项稳定的核心网页指标，它使用 Event Timing API 中的数据来评估响应速度。INP 会观察用户与网页进行的所有互动的延迟时间，并报告所有（或几乎所有）互动所低于的单个值。INP 值较低表示网页能够始终快速响应所有或绝大多数用户互动。

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

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

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

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

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

响应差与响应好的示例。在左侧，长时间运行的任务会阻止手风琴打开。这会导致用户多次点击，以为体验出了问题。当主线程赶上时，它会处理延迟的输入，导致手风琴意外打开和关闭。在右侧，响应速度更快的网页会快速打开手风琴，且不会出现任何问题。

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

什么是 INP？

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

有关 INP 计算方式的详细信息

INP 的计算方法是观察与网页进行的所有互动。对于大多数网站，延迟时间最长的互动会被报告为 INP。

不过，对于互动次数较多的网页，随机出现的故障可能会导致原本响应迅速的网页出现延迟异常高的互动。指定网页上的互动次数越多，这种情况就越有可能发生。

为了更好地衡量互动次数较多的网页的实际响应能力，我们会忽略每 50 次互动中互动次数最高的一次。绝大多数网页体验的互动次数都不超过 50 次，因此系统通常会报告最差的互动。然后，系统会像往常一样报告所有网页浏览的第 75 百分位，这会进一步移除离群值，从而提供绝大多数用户体验到的值或更好的值。

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

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

要点：如需详细了解 INP 的衡量方式，请参阅“什么是互动？”部分。

INP 得分达到多少才算良好？

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

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

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

良好的 INP 值为 200 毫秒或更短。差值大于 500 毫秒。

互动中包含哪些内容？

互动的生命周期。在事件处理程序开始运行之前会发生输入延迟，这可能是由主线程上的长时间运行的任务等因素造成的。然后，互动事件处理程序回调会运行，并且在呈现下一帧之前会发生延迟。

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

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

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

要点：用户还可以通过其他方式与网页互动，例如悬停、缩放或滚动。系统不会为了计算 INP 而观测这些互动。不过，这些互动的一些变体可能包含 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 的最佳方式是从实际用户那里收集指标。如果您习惯于依赖实验数据来评估性能，请花些时间阅读为什么实验数据和实际数据可能有所不同（以及如何解决此问题）。

在实地

理想情况下，您应从实地数据着手优化 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);

注意： 在某些情况下（例如跨源 iframe），无法在 JavaScript 中衡量 INP。如需了解详情，请参阅 web-vitals 库的限制部分。

如何改进 INP

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

更新日志

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

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

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

知识测验

INP 指标的主要目标是什么？

用于衡量网页的首个内容显示所需的时间。

错误 - 此描述的是 First Contentful Paint

用于评估网页需要多长时间才能提供完整交互功能。

错误 - 这与 Time to Interactive 有关，但 INP 专门侧重于对用户输入的响应速度

用于量化网页的视觉稳定性，并最大限度地减少意外的布局偏移。

错误 - 此描述的是 Cumulative Layout Shift

尽量缩短用户发起互动到绘制下一帧之间的时间，适用于用户发起的所有或大多数互动。

正确！

为了计算 INP，系统会观察以下哪种类型的互动？（请选择所有适用选项。）

放大或缩小网页。

不正确 - INP 不考虑缩放

点按触摸屏。

正确！

使用鼠标点击。

正确！

将鼠标光标悬停在元素上。

错误 - INP 不考虑悬停

使用鼠标滚轮或触控板滚动页面。

错误 - INP 不考虑滚动

按键盘上的某个键。

正确！

对于 INP，互动的“延迟时间”是如何定义的？

网页上所有互动产生视觉响应所需的平均时间。

错误 - INP 侧重于最长的互动时间，而不是平均时间

从互动开始到完全呈现下一帧所用的时间。

正确！

浏览器开始处理与互动关联的事件处理程序所用的时间。

错误 - 这仅考虑了输入延迟，而未考虑处理和渲染时间

浏览器处理互动事件处理脚本所用的时间。

错误 - 这仅考虑了处理时长，而未考虑输入延迟或呈现下一帧的时间

INP 和 FID 有何区别？

没有区别；INP 和 FID 只是同一指标的两个不同名称。

错误 - 这两个词的定义确实不同

INP 会考虑所有互动的完整时长，而 FID 仅衡量首次互动的输入延迟时间。

正确！

INP 和 FID 衡量的是网页变为可互动的不同时间戳。

错误 - INP 和 FID 衡量的是网页对互动的响应速度，无论互动何时发生

INP 衡量的是网页首次显示内容所需的时间，而 FID 衡量的是对用户输入的响应速度。

错误 - 此描述的是 First Contentful Paint，而不是 INP

在哪些情况下，PageSpeed Insights 等工具可能无法提供网页的 INP 数据？

来自 Chrome 用户的互动数据不足，无法在 CrUX 数据集中计算出有意义的 INP 值。

正确！

用户仅通过滚动和悬停与网页互动，而这些互动不会纳入 INP 计算。

正确！

该网页是使用可自动针对 INP 进行优化的框架构建的，因此无需报告。

错误 - 框架可以帮助提高 INP，但如果数据可用，该指标仍然相关且会报告

网页使用的是不报告 INP 数据的自定义性能衡量库。

错误 - INP 是使用 Web 平台 API 自动衡量的，不依赖于网页通过自定义库自行报告其性能。

在实验环境中重现缓慢互动的最有效的策略是什么？

侧重于大多数用户不太可能遇到的复杂边缘情况互动。

错误 - 常见用户流更适合用于识别典型的 INP 问题

仅在网页完全加载并处于空闲状态后测试互动。

错误 - 这可能会遗漏加载期间的缓慢互动

模拟高端设备，但网络连接缓慢且不可靠，以创建具有挑战性的条件。

错误 - 虽然网络可能发挥一定作用，但设备功能更有可能暴露缓慢的互动

在加载期间与网页互动，并遵循常见的用户流程来确定潜在的瓶颈。

正确！

✨ 此测验由 Gemini 1.5 生成，并经过人工审核。分享反馈