Interaction to Next Paint (INP)

Chrome 使用情况数据显示，用户 90% 的页面停留时间都是在加载后所花，因此，在整个网页生命周期中仔细衡量响应速度非常重要。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 与 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（以及其他 Core Web Vitals）快速获取 INP 的实测数据。至少，您可以获取网站 INP 的来源级图片，但在某些情况下，您还可以获取网址级数据。

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

实验室

最好是在有实地数据表明网页互动缓慢后，再开始在实验室中进行测试。实测数据可以让在实验室中重现有问题的互动的工作变得更加简单直接。

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

尽管实验室工具在评估网页的 INP 方面存在局限性，但仍有一些策略可用于在实验室中重现缓慢互动。这些策略包括跟踪常见的用户体验流程并测试其中的互动，以及在网页加载时与其互动（此时主线程通常最繁忙），以便在用户体验的关键部分发现互动缓慢的问题。

如何提高 INP

我们提供了一系列关于优化 INP 的指南，可指导您找出现场操作缓慢的互动，并使用实验室数据确定原因并加以优化。

更新日志

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

为帮助您应对此问题，对这些指标的实现或定义所做的所有更改都会显示在此更新日志中。

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

知识测验