redBus 如何改进网站的“交互到下次绘制”(INP) 并将销售额提高了 7%

INP 优化帮助 redBus 将销售额提高了约 7%

Web 及其功能正在快速发展。您现在可以在 Web 上构建丰富且功能齐全的体验,这些体验在功能方面可以实现本地应用程序的大部分功能。

JavaScript 是 Web 交互性的主要驱动力,但如果使用不当,交互可能会感觉迟缓,并导致用户认为您的网站无响应或完全崩溃。值得庆幸的是,创建了“交互到下次绘制”(INP) 指标来解决这个特定的用户体验问题。

INP 衡量页面生命周期内发生的所有交互,并报告一个代表网站响应用户输入速度的单一值。简而言之,如果页面的 INP 达到或低于良好阈值,则可以说与页面进行的所有交互都是可靠快速的。

redBus 是一家总部位于印度的巴士预订和票务网站,他们付出了巨大的努力来改进其网站的 INP,即使在当时它仍被视为实验性指标。由于他们的努力,他们能够将销售额提高 7%,再次说明了 Web 性能与业务健康之间的关系。以下是 redBus 为改进其网站的 INP 所做的工作。

首要目标

当 redBus 着手优化其网站的 INP 时,他们心中有三个目标

  1. 通过关注交互延迟(无论网络速度和设备功能如何)为用户提供更好的用户体验。
  2. 优化他们的网站,以尽可能保持交互快速。
  3. 确保来自其 API 的响应尽可能轻量,以确保快速数据传输到前端。

旅程

redBus 将交互延迟分为两种方式

  1. 客户端阻止 JavaScript 导致的交互延迟。当交互使用过多的 JavaScript 阻止主线程时,渲染会延迟,这会影响页面的 INP。
  2. API 调用引起的网络延迟。虽然网络活动不是 INP 衡量的指标,但在较慢的网络上,或者如果请求导致大量响应,则依赖于远程 API 调用的交互可能会感觉迟缓。

redBus 最初非常有信心其网站的 INP 会很好,但此指标在第 95 个百分位数的真实用户监控 (RUM) 数据讲述了一个不同的故事。

redBus 如何衡量 INP

redBus 依靠 Google 构建的 web-vitals JavaScript 库来跟踪不仅是 INP,还有其网站所有页面的所有重要的用户体验指标。除了 web-vitals JavaScript 库之外,redBus 还使用 ELK 来分析前端收集的 INP 数据。

但是,您在实际环境中跟踪网站 INP 的方式可能与 redBus 解决问题的方式大相径庭。我们强烈建议您阅读关于如何在实际环境中查找慢速交互,以了解如何最好地跟踪您网站的 INP,然后在开始优化交互之前,了解如何在实验室中重现它们

一旦 redBus 建立了一个跟踪 INP 的系统,他们就能够分析数据,以便更好地了解慢速交互存在的位置。

A screenshot of the ELK logging system reporting INP values for analysis.
redBus 用于分析从实际环境中收集的 INP 值的日志记录系统的屏幕截图。(单击以获取此图像的更高分辨率版本。)

用例

当用户在 redBus 网站上搜索票价时,他们可以更改搜索页面上的日期,以筛选所选目的地的票价。在此页面上更改日期的交互速度很慢,是导致 INP 较差的原因之一。

此外,当用户滚动浏览票价时,会从 API 延迟加载更多票价。虽然滚动本身不计入 INP 的衡量方式,但 scroll 事件侦听器本身会安排大量必须在主线程上运行的工作。这项工作导致主线程上的争用增加,从而增加了交互延迟,导致搜索页面上的 INP 较差。

用于从 API 加载更多票价的延迟加载行为。(单击以获取此视频的更高分辨率版本。)

redBus 如何优化搜索页面的 INP

为了改进搜索页面的 INP,redBus 进行了多项优化

  • scroll 事件处理程序被去抖动,以减少事件回调在给定期间触发的次数。通过降低 scroll 事件回调运行的频率,主线程能够更快地响应搜索页面上的用户交互。
  • 通过使用 requestAnimationFrame 回调,渲染工作被优先处理。requestAnimationFrame 告诉浏览器,回调中的工作必须在下一帧之前完成。
A screenshot of the performance panel in Chrome DevTools showing the redBus website firing scroll event callbacks which are not debounced. The result is that the main thread becomes blocked.
之前:滚动处理程序在没有应用去抖动到事件回调的情况下触发。主线程上存在大量阻塞任务,这将延迟交互。
A screenshot of the performance panel in Chrome DevTools showing the redBus website firing scroll event callbacks which are debounced. The result is that the main thread is less blocked because the scroll event handlers fire far less frequently.
之后:滚动处理程序在应用去抖动的情况下触发。滚动事件回调触发频率较低,为主线程提供更多响应用户交互的机会。

此外,还对搜索结果页面进行了以下进一步优化

  • 在搜索结果页面上的倒数第二张卡片上获取新批次的结果,以便通过更早地触发延迟加载来改善用户体验和视觉性能。
  • 在延迟加载期间,每次网络调用获取的结果更少。通过将获取结果从 30 个减少到 10 个,观察到 INP 范围从 870 到 900 降至 350 到 370。
用于从 API 加载更多票价的延迟加载行为。(单击以获取此视频的更高分辨率版本。)

虽然这些更改显着改善了搜索页面的 INP,但仍然存在搜索页面的输入字段上的 change 事件会调用昂贵的 reducer 函数来更新用户界面的问题。这导致了用户界面的不必要重新渲染,从而影响了页面的 INP。

当用户在输入字段中键入时,控制台中报告的 INP 值。在实验室环境中观察到的 344 的 INP 值落在“需要改进”的阈值范围内。(单击以获取此视频的更高分辨率版本。)

为了优化此交互,redBus 在本地管理输入组件的状态,并且仅在输入的 blur 事件触发时才将其与 Redux 存储同步。此更改减少了重新渲染的次数,并通过减少调用 reducer 的频率消除了用户界面的不必要重新渲染。

由于减少了在输入字段更改时调用 reducer 的频率,INP 得到了改善。(单击以获取此视频的更高分辨率版本。)

通过此更改,页面的 INP 提高了 72%,从而带来了更快、更流畅的用户体验,用户更有可能参与其中。

业务影响

业务健康与页面性能之间的关系众所周知。虽然与其他 Core Web Vitals 相比,INP 是一个相对较新的指标,但 redBus 通过专注于改进这个重要的以用户为中心的性能指标,观察到了更好的业务成果。结果是销售额总体增长了 7%。

简而言之,INP 帮助描绘了 redBus 网站上运行时性能问题的画面。有了可以进行改进的知识,redBus 能够观察问题、重现问题,并使用关键信息进行优化,这对 redBus 及其业务都有好处。