了解新的 INP 指标如何影响使用 JavaScript 框架和库构建的网站的体验。
Chrome 最近在 Chrome 用户体验报告中引入了新的实验性响应能力指标。此指标（现在称为 Interaction to Next Paint [INP]）用于衡量网页对用户互动的总体响应情况。今天，我们想分享一些数据洞见，介绍使用现代 JavaScript 框架构建的网站在该指标方面的表现。我们想讨论 INP 为何与框架相关，以及 Aurora 和框架如何优化响应速度。
背景
Chrome 使用 First Input Delay (FID) 作为 Core Web Vitals (CWV) 的一部分来衡量网站的加载响应能力。FIDCWVFID 衡量从用户首次互动到浏览器能够处理与互动相关联的事件处理脚本之间的等待时间。不包括处理事件处理脚本、处理同一网页上的后续互动，或在事件回调运行后绘制下一帧的时间。不过，响应速度对整个网页生命周期内的用户体验至关重要，因为用户在网页加载后的大约 90% 时间都花在网页上。
INP 衡量的是网页从用户发起互动到下一个帧在屏幕上绘制完毕所需的时间。通过 INP，我们希望能够对网页生命周期内所有互动的感知延迟时间进行汇总衡量。我们认为，INP 可更准确地估算网页的加载时间和运行时响应能力。
由于 FID 仅衡量首次互动的输入延迟时间，因此 Web 开发者可能尚未在 CWV 改进流程中主动优化后续互动。因此，网站（尤其是互动度较高的网站）必须开始努力提升这一指标。
框架的作用
由于许多网站依赖 JavaScript 来提供交互性，因此 INP 得分主要受主线程上处理的 JavaScript 量的影响。JavaScript 框架是现代前端 Web 开发的重要组成部分，可为开发者提供有价值的抽象，用于路由、事件处理和 JavaScript 代码的分隔。因此，在优化使用它们的网站的响应能力和用户体验方面，它们起着至关重要的作用。
框架可能已采取措施，通过提前改善网站的 FID 来提高响应速度。不过，他们现在必须分析可用的响应速度指标数据，并努力解决发现的任何问题。一般而言，INP 的通过率往往较低，并且由于测量流程存在差异，因此需要进行额外的代码优化。下表总结了原因。
Chrome 的 Aurora 团队与开源 Web 框架合作，帮助开发者改进用户体验的各个方面，包括性能和 Core Web Vitals 指标。随着 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 会封装用户事件处理脚本。除了 Vanilla JavaScript 之外，实现这些功能还需要额外的框架代码。
Hydration：使用 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 数据。
Angular：Aurora 正在与 Angular 团队合作，探索服务器端渲染和补充方面的改进。我们还计划改进事件处理和更改检测，以提升 INP 的效果。
Vue 和 Nuxt.js：我们正在探索合作途径，主要与脚本加载和呈现相关。
框架如何考虑改进 INP？
React 和 Next.js
React.js 时间切片通过 startTransition 和 Suspense 实现，可让您选择启用选择性或渐进式补充。这意味着，补充水分不是同步块。它会分成小块进行，这些小块可随时中断。
这应该有助于改进 INP，让您能够更快地响应按键操作、过渡期间的悬停效果和点击。这还有助于保持 React 应用的响应能力，即使在进行自动补全等大型转换时也是如此。
Next.js 实现了一个新的路由框架，该框架默认使用 startTransition 进行路由转换。这样，Next.js 网站所有者就可以采用 React 时间切片，并提高路由转换的响应能力。
Angular
Angular 团队正在探索一些也应该有助于 INP 的想法：
- 无分区：缩减初始 bundle 大小，以及应用必须先加载才能呈现任何内容的必需代码。
- 补充水分：采用岛式补充水分，以限制需要唤醒多少应用来进行互动。
- 降低 CD 开销：例如，降低更改检测的开销，寻找减少检查应用的方法，以及利用有关更改内容的响应式信号。
- 更精细的代码拆分：缩减初始软件包的大小。
- 更好地支持加载指示器：例如，在 SSR 重新渲染期间、路线导航期间和延迟加载操作期间。
- 性能分析工具：更好的开发者工具，用于了解互动费用，尤其是特定互动的更改检测费用。
通过这些增强功能，我们可以解决导致响应速度缓慢和用户体验不佳的各种问题，并提升基于框架的网站的 CWV 指标和新的 INP 指标。
总结
我们希望 INP 得分能够更好地为网站指明方向，帮助其提高响应能力和性能。我们将在现有的 INP 指南的基础上，于 2023 年为框架开发者提供更多实用提示。我们希望通过以下方式实现这一目标：
- 创建渠道，以便框架和 Web 开发者轻松访问 INP 中的字段数据。
- 使用框架构建默认会改进 INP 的功能。
我们欢迎框架用户在开始 INP 优化之旅时提供反馈。