Interaction to Next Paint (INP) (与下次绘制的交互)

使用集合保持井井有条 根据您的偏好保存和分类内容。

Chrome 使用数据表明，用户在页面上花费的时间有 90% 是在加载后花费的。因此，在整个页面生命周期中仔细衡量响应速度非常重要。这正是 INP 指标评估的内容。

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

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

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

在以下视频中，右侧的示例立即提供视觉反馈，表明手风琴正在打开。左侧的示例演示了较差的响应速度，以及它如何导致糟糕的用户体验。

本指南解释了 INP 的工作原理、如何衡量它，并指出了改进它的资源。

什么是 INP？

INP 是一个指标，用于评估页面对用户交互的整体响应速度，通过观察用户访问页面期间发生的所有点击、触摸和键盘交互的延迟。最终 INP 值是观察到的最长交互，忽略异常值。

为了更好地衡量具有大量交互的页面的实际响应速度，我们每 50 次交互忽略一次最高交互。绝大多数页面体验的交互次数不超过 50 次，因此通常报告最差的交互。然后像往常一样报告所有页面浏览量的第 75 百分位数，这进一步消除了异常值，从而给出一个绝大多数用户体验或更好的值。

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

要点： 有关 INP 如何测量的更多详细信息，请阅读“交互中包含什么？”部分。

什么是好的 INP 分数？

在响应速度指标上贴上“好”或“差”之类的标签是很困难的。一方面，您希望鼓励优先考虑良好响应速度的开发实践。另一方面，您必须考虑到人们使用的设备的功能存在相当大的差异，以便设定可实现的开发期望。

• 为了确保您提供具有良好响应速度的用户体验，一个好的衡量阈值是在现场记录的页面加载的 75% 百分位数，按移动设备和桌面设备细分
• INP 低于或等于 200 毫秒意味着页面具有良好的响应速度。
• INP 高于 200 毫秒且低于或等于 500 毫秒意味着页面的响应速度需要改进。

良好的 INP 值是 200 毫秒或更少。较差的值大于 500 毫秒。

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

交互性的主要驱动因素通常是 JavaScript，尽管浏览器确实通过并非由 JavaScript 驱动的控件提供交互性，例如复选框、单选按钮和由 CSS 驱动的控件。

• 出于 INP 的目的，仅观察以下交互类型：
• 使用鼠标点击。
• 在触摸屏设备上触摸。

要点： 用户也可能以其他方式与页面交互，例如悬停、缩放或滚动。出于 INP 的目的，不会观察这些交互。但是，这些交互的某些变体可能包括 INP 确实会衡量的手势，例如点击、触摸或按键。

交互发生在主文档或嵌入在文档中的 iframe 中——例如，单击嵌入视频上的播放。最终用户不会知道 iframe 中包含什么，因此，需要 iframe 中的 INP 来衡量顶级页面的用户体验。由于 JavaScript Web API 无权访问 iframe 的内容，这可能会显示为 CrUX 和 RUM 之间的差异

具有多个事件处理程序的交互的描述。交互的第一部分在用户单击鼠标按钮时接收输入。但是，在他们释放鼠标按钮之前，会呈现一个帧。当用户释放鼠标按钮时，在呈现下一个帧之前，必须运行另一系列事件处理程序。

页面的 INP 在用户离开页面时计算。结果是一个单一值，代表页面在其整个生命周期内的整体响应速度。低 INP 值意味着页面能够可靠地响应用户输入。

INP 与首次输入延迟 (FID) 有何不同？

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

这些差异意味着 INP 和 FID 是不同类型的响应速度指标。FID 是一个加载响应速度指标，旨在评估页面给用户的最初印象，而 INP 是整体响应速度的更可靠指标，无论交互发生在页面生命周期的哪个阶段。

如果没有报告 INP 值怎么办？

• 页面有可能不返回 INP 值。这可能是由于多种原因造成的，包括以下原因
• 页面已加载，但用户从未单击、触摸或按下键盘上的按键。
• 页面已加载，但用户使用未衡量的手势与其交互，例如滚动或悬停在元素上。

页面正在被机器人（例如搜索爬虫或无头浏览器）访问，这些机器人未被脚本化以与页面交互。

如何衡量 INP

要点： 衡量您网站 INP 的最佳方法是从现场的实际用户那里收集指标。如果您习惯于依赖实验室数据来评估性能，请花一些时间阅读《为什么实验室数据和现场数据可能不同（以及如何处理）》。

在现场

阅读以了解更多信息： 《在现场查找缓慢的交互》。

如果您的网站符合纳入 Chrome 用户体验报告 (CrUX) 的条件，您可以通过 PageSpeed Insights 中的 CrUX（以及其他 Core Web Vitals）快速获取 INP 的现场数据。至少，您可以获得网站 INP 的来源级别概览，但在某些情况下，您也可以获得 URL 级别的数据。

但是，虽然 CrUX 可以告诉您是否存在问题，但它无法告诉您问题的原因。RUM 解决方案可以帮助您发现有关页面、用户或用户交互的更多详细信息，这些页面、用户或用户交互正在经历响应速度问题。能够将 INP 归因于个别交互可以避免猜测和浪费精力。

在实验室中

最佳情况下，一旦您拥有表明页面存在缓慢交互的现场数据，您就希望开始在实验室中进行测试。现场数据将使在实验室中重现有问题的交互的工作变得更加直接。

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

阅读以了解更多信息： 《在实验室中手动诊断缓慢的交互》。

如何改进 INP

提供了一系列关于优化 INP 的指南，以指导您完成在现场识别缓慢交互以及使用实验室数据帮助您识别原因并优化它们的过程。

更新日志

有时，在用于衡量指标的 API 中会发现错误，有时在指标本身的定义中也会发现错误。因此，有时必须进行更改，这些更改可能会在您的内部报告和仪表板中显示为改进或回归。

为了帮助您管理这一点，对这些指标的实现或定义的所有更改都将在此更新日志中公布。

如果您对这些指标有反馈，请在 web-vitals-feedback Google 网上论坛中提供。