与下一个油漆的相互作用 (INP)

“交互到下一帧绘制”衡量页面对用户输入的视觉响应速度，其数值代表用户访问期间遇到的最差交互延迟。该指标于 2024 年 3 月取代“首次输入延迟”成为 Core Web Vitals 的响应速度指标，这一变化意义重大：旧指标仅记录首次交互开始处理之前的延迟，而新指标则衡​​量会话中所有交互从输入到处理完成再到下一帧绘制完成的完整时间。

这种差异至关重要，因为之前的指标对许多网站来说过于乐观。一个页面可能显示首次输入延迟很低，但实际加载速度却很慢，因为该指标忽略了事件处理程序运行所需的时间以及浏览器渲染结果所需的时间，而且它只关注一次交互。在旧指标下看起来响应迅速的网站，在新指标下往往并非如此，尤其是单页应用程序和任何包含大量客户端逻辑的界面。

报告值源自观察到的最长交互时间，并考虑了交互次数较多的页面上的异常值。谷歌公布的阈值将 200 毫秒或更短视为真实用户体验中 75% 分位数的良好表现。由于它涵盖了从输入到渲染的整个路径，因此低分可能源于以下几个方面：主线程上的长时间任务阻塞浏览器处理事件；事件处理程序同步执行过多工作；交错读写样式导致的布局抖动；以及状态更改后耗时的渲染。

诊断结果通常指向 JavaScript 执行问题，而非网络状况，这使得该指标区别于负载指标。常见原因包括：大型单体包在主线程上执行、第三方脚本在交互期间执行任意操作、框架重新渲染时涉及的组件树范围远超实际所需，以及处理程序执行本可以延迟或移出主线程的同步计算。大多数情况下，耗时过长的任务是根本原因，因为浏览器在任务运行时无法响应输入。

诊断之后是修复。将耗时较长的任务拆分成更小的片段，并显式地让出空闲时间，可以让浏览器在片段之间处理输入。将非必要的工作延迟到视觉更新之后，使用户能够立即看到响应，可以解决最常见的问题。减少 JavaScript 的加载量、审核第三方脚本的主线程开销、虚拟化长列表以及将繁重的计算任务迁移到工作线程，分别针对不同的问题根源。为缓慢的操作提供即时的视觉反馈并不会改善实际的性能指标，但可以改变用户对延迟的感知。

第三方脚本值得特别关注，因为它们是造成性能问题的一个常见原因，而且不受团队的直接控制。聊天窗口、用户许可管理器、分析库、个性化工具和广告脚本都在主线程上运行，并且可能在访客尝试交互时占用主线程资源。理想情况下，应该通过对比启用和禁用第三方脚本的页面性能来审核每个脚本的主线程开销，这样就能得到一份具体的清单，列出每个供应商在响应速度方面的成本。有了这个数据，就可以与申请使用该工具的团队讨论权衡利弊，这通常比试图围绕一个占用大部分可用预算的脚本来优化应用程序代码要高效得多。

由于该指标由应用程序代码驱动，而非由资产交付驱动，因此改进它通常需要工程工作，而非配置。实际上，它处于两者之间的边界。 网络性能 和 产品开发对于交互式商务和预订界面而言，这种情况尤其严重，因为筛选、配置和购物车交互无响应会导致用户放弃购买，而分析结果显示为普通的流失，却没有明显的原因。