Interaction to Next Paint（INP）

作者：林语者 分类：工程代码

Browser Support

96 96 x

Source

注: Interaction to Next Paint (INP) 是基于 Event Timing API 数据评估响应性的稳定版核心网页指标。INP 会监测用户在页面上进行的所有交互的延迟，并报告一个所有（或几乎所有）交互都低于的单一值。较低的 INP 值意味着页面能够对所有或大部分用户交互做出快速且一致的响应。

根据 Chrome 使用情况数据显示，用户在页面上花费的时间有 90% 是在页面加载之后。因此，仔细测量整个页面生命周期的响应性至关重要，INP 指标正是为此设计。

高响应性意味着页面能对操作做出快速响应。当页面响应交互时，浏览器会在下一帧显示视觉反馈。例如，您可以直观地看到在线购物车中的商品是否成功添加、移动导航菜单是否打开，或者登录表单内容是否通过服务器验证。

某些操作自然比其他操作需要更多时间，但快速提供初始视觉反馈以告知用户正在发生的事情非常重要，尤其是在处理复杂操作时。浏览器下一次绘制帧是完成此操作的最早时机。

因此，INP 的目的并非测量交互的所有最终效果（如网络获取或其他异步操作带来的 UI 更新），而是测量下一次绘制被阻塞的时间。视觉反馈的延迟会让用户感觉页面响应不够快。INP 的开发目的正是让开发者能够量化用户体验中的这一环节。

在下方视频的右侧示例中，您可以立即看到手风琴展开的视觉反馈。左侧示例则展示了低响应性如何导致用户体验下降。

响应性差的示例和良好的示例。左侧，长任务阻塞了手风琴的展开。用户会认为体验已损坏，从而反复点击。当主线程恢复处理时，延迟的输入被处理，导致手风琴意外地开合。右侧响应性良好的页面则能快速打开手风琴，不会出现问题。

本指南将介绍 INP 的工作原理、测量方法以及有助于优化的资源。

INP 是什么

INP 是一项通过监测用户访问页面全过程中发生的所有点击、轻触和键盘操作的延迟，来评估页面整体响应性的指标。最终的 INP 值是监测到的延迟最大的交互（忽略异常值）。

INP 的计算方法详情 INP 通过监测页面上发生的所有交互来计算。对于大多数网站，延迟最长的交互将被报告为 INP。 然而，在交互次数较多的页面上，随机延迟可能会导致响应性良好的页面出现异常高延迟的交互。特定页面上的交互越频繁，发生这种现象的可能性就越大。 为了更准确地衡量交互密集型页面的实际响应性，INP 会忽略每 50 次交互中最高的那一次。由于大多数页面体验不会超过 50 次交互，因此通常报告的是最差的交互。同时，所有页面浏览的第 75 百分位数会照常报告，这进一步排除了异常值，从而得到大多数用户所体验到的值。

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

交互的延迟是指从用户开始交互到浏览器能够绘制下一帧为止的时间，它由驱动该交互的事件处理程序组的最长持续时间构成。在极少数情况下，交互可能会在浏览器能够绘制帧时结束，即使此时没有需要绘制的帧。

关键点: 有关 INP 测量方法的更多详细信息，请参阅“什么是交互”部分。

良好的 INP 分数

为响应性指标固定“良好”或“不良”等标签具有一定挑战性。一方面我们希望推广响应式开发实践，另一方面由于用户设备性能差异巨大，需要设定切实可行的开发目标。

为了提供响应迅速的用户体验，我们建议使用按移动设备和桌面设备细分、并在真实用户环境中记录的页面加载第 75 百分位数作为阈值：

  • INP ≤ 200 毫秒：表示页面响应性良好。
  • 200 毫秒 < INP ≤ 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 与首次输入延迟 (FID) 有何不同？

INP 是首次输入延迟 (FID) 的继承者。两者都是响应性指标，但 FID 仅测量页面首次交互的输入延迟。INP 则通过监测页面上所有交互（从输入延迟到事件处理程序执行时间，再到浏览器绘制下一帧的时间），从而改进了 FID。

这一区别表明，虽然 INP 和 FID 都是响应性指标，但侧重点不同。FID 旨在评估用户对页面的第一印象，属于加载响应性指标；而 INP 则能更可靠地指示整体响应性，无论交互发生在页面生命周期的哪个阶段。

未报告 INP 值的情况

有时页面可能不会返回 INP 值。这种情况可能由以下原因引起：

  • 页面已加载，但用户未进行任何点击、轻触或键盘按键操作。
  • 页面已加载，但用户仅通过未测量的手势（如滚动或将光标移到元素上）进行操作。
  • 访问者是搜索爬虫或无头浏览器等机器人，这些机器人未配置为与页面交互。

INP 的测量方法

INP 可以在真实用户环境 (Field) 和实验室环境 (Lab) 中进行测量，但后者受限于其模拟真实用户交互的能力。

关键点: 测量网站 INP 的最佳方法是从真实用户那里收集指标数据。如果您习惯使用实验室数据进行性能评估，请阅读实验室数据与真实用户数据差异的原因及应对方法。

真实用户环境 (Field)

理想情况下，INP 的优化应从真实用户数据开始。真实用户监控 (RUM) 数据不仅提供页面的 INP 值，还提供了宝贵的上下文数据，帮助高亮显示影响响应性的交互细节，例如导致 INP 值的具体交互、交互发生在页面加载期间还是加载之后、交互类型（点击、按键、轻触）以及其他有助于确定交互哪部分导致问题的计时数据。

详细信息: 在真实环境中查找缓慢的交互。

如果您的网站被纳入 Chrome 用户体验报告 (CrUX)，您可以通过 PageSpeed Insights 快速获取 INP 的真实用户数据（以及其他核心网页指标）。至少可以获得网站源站级别的 INP 概览，有时甚至可以获得 URL 级别的数据。

但 CrUX 只能告诉您是否存在问题，而无法揭示问题原因。使用 RUM 解决方案可以获取更详细信息，了解出现响应性问题的具体页面、用户和用户操作。能够将 INP 归因于具体的交互，可以避免猜测和无效劳动。

实验室环境

理想情况下，当您获得真实用户数据表明页面存在交互延迟时，就可以开始在实验室中进行测试。拥有真实用户数据会使在实验室中复现问题交互的工作变得简单得多。

但是，也可能没有真实用户数据。虽然 INP 可以在一些实验室工具中测量，但页面在实验室测试期间的 INP 值取决于测试期间执行的交互。由于用户行为难以预测且变化很大，实验室测试可能无法重现真实环境中出现的问题交互组合。此外，一些实验室工具仅观察页面加载而无交互，因此不会报告页面的 INP。在这种情况下，总阻塞时间 (TBT) 可以作为 INP 的合理代理指标，但它本身并不能替代 INP。

尽管实验室工具评估 INP 存在局限性，但仍有一些策略可以在实验室中复现缓慢的交互。例如，遵循常见用户流程进行测试并在过程中测试交互的策略，或者在页面加载期间（此时主线程通常最繁忙）进行交互以识别导致用户体验关键部分交互变慢的原因。

详细信息: 在实验室中手动诊断缓慢的交互。

使用 JavaScript 测量 INP

要使用 JavaScript 测量 INP，您需要测量所有交互的事件计时，并在页面卸载时获取这些交互的第 98 百分位数值。有关 INP 计算方法的参考实现，请参阅 web-vitals JavaScript 库的源代码。

在大多数情况下，页面卸载时的当前 INP 值就是该页面的最终 INP 值，但存在一些重要的例外情况（如下一节所述）。web-vitals JavaScript 库在 Web API 限制范围内尽可能考虑了这些因素。

指标与 API 的差异

  • 如果 event 条目的持续时间少于 104 毫秒，则默认情况下不会通过 Performance Observer 进行报告。您可以在注册 Performance Observer 时使用 durationThreshold 参数更改此默认值，但最小值仍为 16 毫秒。因此，建议同时监视 first-input 条目（它也是事件计时条目，但即使持续时间短于 durationThreshold 也能被监测到。这确保包含交互的页面始终报告 INP 值。
  • 要精确计算百分位数，需要将所有样本保留在内存中，这可能成本高昂。但是，仅维护一个包含最差 N 次交互的小列表就足以近似非常高（例如 p98）的百分位数。通常选择 10。
  • 如果页面从往返缓存中恢复，用户会将其视为另一次页面访问，因此 INP 值应重置为零。
  • API 不报告在 iframe 内发生的交互的 event 条目，但指标应包含它们，因为 iframe 内的交互是页面用户体验的一部分。这可能导致 CrUX 和 RUM 之间出现差异。要正确测量 INP，需要考虑这些因素。子框架可以使用 API 将 event-timing 条目报告给父框架。

除了这些例外情况，由于 INP 测量整个页面生命周期，复杂性也随之增加：

  • 用户可能将标签页保持打开状态非常长的时间（数天、数周、数月）。
  • 在移动操作系统中，浏览器通常不会对后台标签页执行页面卸载回调，因此难以报告“最终”值。

为了处理这些情况，INP 应在页面每次转为后台时报告（而不仅仅是在卸载时报告），visibilitychange 事件可以覆盖这两种场景。接收此数据的分析系统需要在后端计算最终的 INP 值。

开发者无需自行处理所有这些情况，可以使用 web-vitals JavaScript 库来测量 INP。该库处理了上述所有情况（iframe 情况除外）。

import {onINP} from 'web-vitals';
// 在所有需要报告的情况下测量并记录 INP
onINP(console.log);

注: 在某些情况下（例如跨源 iframe），可能无法使用 JavaScript 测量 INP。有关详细信息，请参阅 web-vitals 库的限制。

如何改善 INP

INP 优化指南集 介绍了如何通过真实用户数据识别缓慢交互，并利用实验室数据诊断原因并进行优化的过程。

变更记录

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

为便于管理，所有对这些指标的实现或定义的更改都将记录在此变更日志中。

如果您对这些指标有反馈，请发送至 web-vitals-feedback Google 群组。

理解度测试

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

  • [ ] 测量页面首次内容显示的时间。
    • 错误 - 这是首次内容绘制 (FCP) 的描述。
  • [ ] 量化页面的视觉稳定性，并最小化意外的布局偏移。
    • 错误 - 这是累积布局偏移 (CLS) 的描述。
  • [ ] 评估页面完全可交互所需的时间。
    • 错误 - 这与可交互时间 (TTI) 相关，但 INP 特别关注用户输入的响应性。
  • [x] 最小化用户发起的交互中，从开始到下一帧绘制完成的时间。
    • 正确。

为计算 INP，会观测以下哪些类型的交互？（选择所有适用的选项）

  • [x] 用鼠标点击。
    • 正确。
  • [ ] 用鼠标滚轮或触控板滚动页面。
    • 错误 - INP 不考虑滚动。
  • [x] 轻触触摸屏。
    • 正确。
  • [ ] 将鼠标光标悬停在元素上。
    • 错误 - INP 不考虑悬停。
  • [x] 按下键盘上的按键。
    • 正确。
  • [ ] 放大或缩小页面。
    • 错误 - INP 不考虑缩放。

INP 中如何定义交互的“延迟”？

  • [ ] 浏览器处理交互的事件处理程序所需的时间。
    • 错误 - 这仅考虑了处理时间，未包括输入延迟和下一帧显示的时间。
  • [ ] 页面上所有操作产生视觉反馈所需的平均时间。
    • 错误 - INP 关注的是最长的交互，而非平均值。
  • [ ] 浏览器开始处理与交互关联的事件处理程序之前的时间。
    • 错误 - 这只考虑了输入延迟，未包括处理时间和渲染时间。
  • [x] 从交互开始到下一帧完全显示之间的时间。
    • 正确。

INP 和 FID 有什么区别？

  • [ ] INP 测量页面首次内容显示的时间，而 FID 测量用户输入的响应性。
    • 错误 - 这是首次内容绘制 (FCP) 的描述，而非 INP。
  • [x] INP 考虑所有交互的整个持续时间，而 FID 仅测量首次交互的输入延迟。
    • 正确。
  • [ ] INP 和 FID 测量页面变为可交互的不同时间点。
    • 错误 - INP 和 FID 都是测量页面响应交互时间的指标。
  • [ ] 没有区别。INP 和 FID 是同一指标的两个不同名称。
    • 错误 - 它们有不同的定义。

在 PageSpeed Insights 等工具中，什么情况下页面的 INP 数据可能不可用？

  • [ ] 页面使用了不报告 INP 数据的自定义性能测量库。
    • 错误 - INP 是使用 Web Platform API 自动测量的，不依赖页面通过自定义库自行报告性能。
  • [x] CrUX 数据集中没有足够的 Chrome 用户交互数据来计算有意义的 INP 值。
    • 正确。
  • [x] 用户仅通过滚动和悬停与页面交互，这些不包括在 INP 计算中。
    • 正确。
  • [ ] 该页面是使用为 INP 自动优化的框架构建的，因此无需报告。
    • 错误 - 框架可能有助于改善 INP，但只要数据可用，该指标仍然相关且会被报告。

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

  • [ ] 模拟网络连接缓慢不稳定的高端设备，以创造困难条件。
    • 错误 - 虽然网络可能有影响，但设备性能通常更易暴露缓慢交互。
  • [ ] 仅在页面完全加载并处于空闲状态后才测试交互。
    • 错误 - 这可能会错过加载期间发生的缓慢交互。
  • [x] 在页面加载期间就与之交互，并沿着常见的用户流程识别潜在的瓶颈。
    • 正确。
  • [ ] 专注于大多数用户不会遇到的复杂边缘案例交互。
    • 错误 - 常见的用户流程对于识别典型的 INP 问题更为重要。

✨ 此测验由 Gemini 1.5 生成，并经过人工审核。欢迎提供反馈！

标签： 性能优化

评论

发表评论

正在加载评论...