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