了解新的 INP 指标对使用 JavaScript 框架和库构建的网站的体验有何影响。
Chrome 最近在 Chrome 用户体验报告报告中引入了一个新的实验性响应速度指标。该指标（我们现在称为 Interaction to Next Paint (INP)）用于衡量对网页上的用户互动的总体响应情况。今天，我们想分享一些见解，让您了解使用现代 JavaScript 框架构建的网站在哪些方面与该指标相关。我们想要讨论一下为什么 INP 与框架相关，以及 Aurora 和框架如何致力于优化响应能力。
背景
Chrome 使用 First Input Delay (FID) 作为核心网页指标 (CWV) 的一部分来衡量网站的加载响应速度。FID 衡量从首次用户互动到浏览器能够处理连接到互动的事件处理脚本这段时间的等待时间。但并不包括处理事件处理脚本、处理同一网页上的后续互动或绘制事件回调运行后绘制下一帧所用的时间。不过，响应能力在整个网页生命周期中对于用户体验至关重要，因为用户在网页加载后大约有 90% 的时间在页面上停留。
INP 衡量的是从用户开始互动到下一帧在屏幕上绘制完成的那一刻，网页响应用户互动所用的时间。通过 INP，我们希望能够对网页生命周期内所有互动的感知延迟时间进行汇总衡量。我们相信，INP 可以更准确地估算网页的加载和运行时响应速度。
由于 FID 仅衡量首次互动的输入延迟，因此 Web 开发者可能没有在其 CWV 改进过程中主动优化后续互动。因此，网站（尤其是具有较高互动性的网站）必须开始努力在此指标上取得良好表现。
框架的作用
由于许多网站依靠 JavaScript 来提供互动性，因此 INP 得分主要受主线程上处理的 JavaScript 数量的影响。JavaScript 框架是现代前端 Web 开发的重要组成部分，可为开发者提供有价值的抽象，以实现 JavaScript 代码的路由、事件处理和划分。因此，它们在优化使用它们的网站的响应性和用户体验方面发挥着核心作用。
框架可能已经采取措施，通过提前改进网站的 FID 来提升响应速度。但是，他们现在必须分析可用的响应能力指标数据，并努力弥补已发现的所有差距。一般而言，INP 的通过率往往较低，且衡量流程中的差异需要进行额外的代码优化。下表总结了原因。
Chrome 中的 Aurora 团队使用开源 Web 框架，帮助开发者改善用户体验的不同方面，包括性能和 CWV 指标。随着 INP 的推出，我们希望为基于框架的网站的 CWV 指标的变化做好准备。我们已根据 CrUX 报告中的实验性响应能力指标收集数据。我们将分享分析洞见和行动项，帮助基于框架的网站轻松过渡到 INP 指标。
实验性响应速度指标数据
INP 低于或等于 200 毫秒表示响应速度快。2023 年 6 月的 CrUX 报告数据和 CWV 技术报告为我们提供了有关热门 JavaScript 框架的响应速度的信息。
此表格会显示每个框架上响应速度得分较高的来源所占的百分比。这些数字很鼓舞人心，但我们仍认为还有很大的改进空间。
JavaScript 对 INP 有何影响？
实测的 INP 值与实验室中观察到的总阻塞时间 (TBT) 非常相关。这可能意味着，长时间阻塞主线程的任何脚本都对 INP 来说都是不利的。在任意交互之后大量 JavaScript 执行可能会长时间阻塞主线程并延迟对该交互的响应。导致脚本被屏蔽的一些常见原因包括：
未优化的 JavaScript：代码冗余或糟糕的代码拆分和加载策略可能会导致 JavaScript 膨胀，并长时间阻塞主线程。拆分代码、渐进式加载和分解长任务可显著缩短响应时间。
第三方脚本：处理互动有时不需要的第三方脚本（例如广告脚本）可能会阻塞主线程并造成不必要的延迟。优先使用重要脚本有助于减少第三方脚本的负面影响。
多个事件处理脚本：与每次互动相关联的多个事件处理脚本，每个处理脚本都运行不同的脚本，可能会相互干扰，最终导致长时间的延迟。其中一些任务可能不是必要的任务，可以在 Web Worker 上或在浏览器空闲时安排。
事件处理的框架开销：框架可能具有额外的事件处理功能/语法。例如，Vue 使用 v-on 将事件监听器附加到元素，而 Angular 封装用户事件处理脚本。实现这些功能需要在原版 JavaScript 上方添加其他框架代码。
水合：使用 JavaScript 框架时，服务器为网页生成初始 HTML 并不罕见，该网页随后需要通过事件处理程序和应用状态进行增强，以便在网络浏览器中实现互动。我们将这个过程称为“水合”。此过程在加载期间可能会是一个繁重的过程，具体取决于 JavaScript 的加载和饮水完成所需的时间。这也可能会导致网页看起来像是互动式的，而实际上并非是互动的。通常在网页加载时自动进行或延迟进行（例如，在用户互动时），并且因任务调度而影响 INP 或处理时间。在 React 等库中，您可以利用
useTransition，使组件渲染的部分内容位于下一帧中，而代价较高的副作用则留给未来的帧。有鉴于此，在过渡过程中，如果更新会转化为点击等更紧急的更新，这种模式就可能适合 INP。预提取：如果处理得当，积极预提取后续导航所需的资源可以提升性能。但是，如果您同步预提取和渲染 SPA 路由，最终可能会对 INP 产生负面影响，因为所有这些代价高昂的渲染都尝试在单个帧中完成。与之相对，它不预提取路线，而是启动所需工作（例如，
fetch()）并取消屏蔽绘制。我们建议重新检查框架的预提取方法是否提供了最佳用户体验，以及这可能会对 INP 产生怎样的影响（如果有的话）。
从现在开始，为了获得良好的 INP 得分，开发者必须专注于检查网页上每次互动后执行的代码，并针对第一方脚本和第三方脚本优化分块、重构、加载策略以及每次 render() 更新的大小。
Aurora 和框架如何解决 INP 问题？
Aurora 融合了最佳实践，可为常见问题提供内置解决方案。我们已与 Next.js、Nuxt.js、Gatsby 和 Angular 合作开发了解决方案，这些解决方案在框架内提供强大的默认值来优化性能。以下是我们在这方面的工作的亮点：
React 和 Next.js：Next.js 脚本组件有助于解决因第三方脚本加载效率低下而导致的问题。精细分块是在 Next.js 中引入的，旨在为共享代码提供较小大小的分块。这有助于减少从所有网页上下载的未使用的通用代码的数量。我们还在与 Next.js 合作，将 INP 数据作为其 Google Analytics（分析）服务的一部分。
Angular：Aurora 与 Angular 团队合作，探索服务器端渲染和水合的改进。我们还计划优化事件处理和变化检测，以改进 INP。
Vue 和 Nuxt.js：我们正在探索合作途径，主要涉及脚本加载和渲染。
各个框架是如何考虑改进 INP 的？
React 和 Next.js
借助通过 startTransition 和 Suspense 实现的 React.js 时间切片，您可以选择选择性或渐进式水合。这意味着 hydration 不是同步块。它是在小片中完成的，并且可以随时中断。
这应该有助于改进 INP，让您能更快地响应按键、过渡期间的悬停效果以及点击。它还有助于让 React 应用能够快速响应，即使是大型过渡（例如自动补全）也不例外。
Next.js 实现了新的路由框架，该框架默认使用 startTransition 进行路由转换。这使得 Next.js 网站所有者能够采用 React 时间切片并提升路线转换的响应速度。
Angular
Angular 团队正在探索几个对 INP 也有帮助的想法：
- 无可用区：缩减初始 bundle 大小，以及应用呈现任何内容之前必须加载的必需代码。
- 饮水：岛式饮水功能，限制需要唤醒应用多少内容进行互动。
- 降低持续交付的开销：例如，降低变更检测的成本、找到减少应用检查数量的方法，以及利用与变更内容相关的反应信号。
- 更精细的代码拆分：减小初始 bundle。
- 更好地支持加载指示器：例如，在 SSR 重新渲染期间、路线导航期间和延迟加载操作期间。
- 性能剖析工具：提供更出色的开发者工具，有助于了解互动费用，尤其是特定互动的变化检测费用。
通过这些增强功能，我们可以解决导致响应速度和用户体验不佳的不同问题，并提升基于框架的网站的 CWV 指标和新的 INP 指标。
总结
我们预计 INP 得分能够为网站将来改进响应速度和性能提供更好的指导。我们将在现有 INP 指南的基础上，于 2023 年为框架开发者提供更多切实可行的提示。我们希望通过以下方式实现这一目标：
- 为框架和 Web 开发者创建渠道，以便轻松访问 INP 上的现场数据。
- 使用框架构建功能，以默认改进 INP。
欢迎框架用户在开始 INP 优化历程时提供反馈。