Chrome 使用情况数据显示，用户 90% 的页面停留时间都是在加载后所花，因此，在整个网页生命周期中仔细衡量响应速度非常重要。这是 INP 指标评估的内容。
良好的响应速度意味着网页可以快速响应互动。当网页响应互动时，浏览器会在其绘制的下一帧中提供视觉反馈。例如，视觉反馈会告诉您是否确实添加了您添加到在线购物车中的商品、移动导航菜单是否打开、服务器是否正在对登录表单的内容进行身份验证等。
有些互动的用时自然要比其他互动长，但对于特别复杂的互动，必须快速显示一些初始视觉反馈，让用户知道正在发生某件事。浏览器要绘制的下一帧是最早执行此操作的机会。
因此，INP 的目的不是衡量互动的所有最终影响（例如来自其他异步操作的网络提取和界面更新），而是衡量下一次绘制被阻塞的时间。延迟视觉反馈可能会让用户觉得页面响应速度不够快，因此开发了 INP，旨在帮助开发者衡量这部分用户体验。
在下面的视频中，右侧示例直接直观地反馈了手风琴正在开启。如左侧示例所示，响应能力很差，以及它如何导致糟糕的用户体验。
本指南介绍了 INP 的运作方式、衡量方法，并提供了改进 INP 的资源。
什么是 INP？
INP 是一项指标，通过观察用户在访问网页的整个生命周期内发生的所有点击、点按和键盘互动的延迟时间，评估网页对用户互动的总体响应情况。最终 INP 值是观测到的最长互动时间，离群值会被忽略。
INP 是通过观察用户与网页进行的所有互动计算得出的。对于大多数网站，延迟时间最长的互动会报告为 INP。
不过，对于具有大量互动的网页，随机中断可能会导致在响应迅速的网页上进行互动。网页上发生的互动越多，发生这种情况的可能性就越大。
为了更好地衡量互动次数较多的网页的实际响应速度，我们会忽略每 50 次互动中一次最高的互动。绝大多数网页体验都不到 50 次互动，因此最差的互动最常被报告。然后，系统会照常报告所有网页浏览量的第 75 个百分位，从而进一步移除离群值，从而给出绝大多数用户体验或更好的值。
互动是指在同一逻辑用户手势期间触发的一组事件处理脚本。例如，“点按”触摸屏设备上的互动包括多个事件，例如 pointerup、pointerdown 和 click。互动可由 JavaScript、CSS、内置浏览器控件（例如表单元素）或以上各项的组合驱动。
互动的延迟时间包括从用户开始互动到浏览器绘制下一帧这一时刻，驱动互动的一组事件处理脚本的单个最长时长。
INP 得分怎样才算高？
固定标签，如“good”（好）或“糟糕”很难衡量响应速度一方面，您要鼓励开发实践优先采用良好的响应能力。另一方面，您必须考虑到人们用于设定可实现开发期望的设备的功能存在很大差异。
为确保提供高响应性用户体验，比较理想的衡量阈值是现场记录的网页加载的第 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（以及其他核心网页指标）快速获取 INP 的实测数据。您至少可以获取网站 INP 的原始级别的信息，但在某些情况下，您还可以获取网址级别的数据。
不过，虽然 CrUX 可以告诉您是否存在问题，但它无法告诉您导致问题的原因。RUM 解决方案可帮助您发现有关遇到响应问题的网页、用户或用户互动的更多详细信息。将 INP 归因于单个互动可以避免猜测和浪费工作。
实验室
理想情况下，在掌握了表明某网页互动速度缓慢的实测数据后，您就可以开始在实验室中进行测试。实测数据可以让在实验室中重现有问题的互动的工作变得更加简单直接。
不过，您完全可能没有字段数据。虽然可以使用某些实验室工具衡量 INP，但在实验室测试期间为网页生成的 INP 值将取决于在衡量期间进行的互动。用户行为可能不可预测且变化很大，这意味着您在实验室中的测试可能无法像实测数据那样通过呈现问题交互的方式。此外，某些实验工具不会报告网页的 INP，因为它们只会观测到网页加载情况没有任何互动。在这种情况下，总阻塞时间 (TBT) 可能是 INP 的合理替代指标，但其本身无法替代 INP。
尽管实验室工具在评估网页的 INP 方面存在局限性，但仍有一些策略可以在实验室中重现缓慢互动。这些策略包括跟踪常见的用户流并在整个过程中测试互动，以及在页面加载时（主线程通常最繁忙时）与其交互，以便确定用户体验的关键阶段期间的缓慢互动。
如何改进 INP
我们提供了一系列关于优化 INP 的指南，可指导您找出现场操作缓慢的互动，并使用实验室数据确定原因并加以优化。
更新日志
有时，错误是在用于衡量指标的 API 中发现的，有时是在指标本身的定义中发现的。因此，有时必须进行更改，这些更改可能会在内部报告和信息中心显示为改进或回归。
为帮助您应对此问题，对这些指标的实现或定义所做的所有更改都会显示在此更新日志中。
如果您对这些指标有反馈意见，请在 web-vitals-feedback Google 群组中提供。
知识测验
INP 指标的主要目标是什么？
为了计算 INP，系统会观察到以下哪种互动类型？（请选择所有适用选项。）
“延迟时间”如何？为 INP 定义的互动？
INP 和 FID 有何区别？
在什么情况下，PageSpeed Insights 等工具可能无法提供网页的 INP 数据？
要在实验室环境中重现缓慢互动，最有效的策略是什么？
✨ 此测验由 Gemini 1.5 生成并经过人工审核。欢迎分享反馈