redBus、INP の最適化で売上が約 7% 増加
ウェブとその機能は速いペースで進化しています。機能面でネイティブ アプリの多くを実現できる、リッチでフル機能のウェブ エクスペリエンスを構築できるようになりました。
JavaScript はウェブでのインタラクティビティの主要な要因ですが、慎重に使用しないと操作が遅く感じられ、ユーザーはウェブサイトが応答していない、またはまったく機能していないと認識する可能性があります。幸いなことに、Interaction to Next Paint（INP）指標は、このようなユーザー エクスペリエンスの問題に対処するために作られました。
INP は、ライフサイクル中にページで行われたすべてのインタラクションを測定し、ウェブサイトのユーザー入力に応答する速度を表す単一の値を報告します。簡単に言うと、ページの INP が良好しきい値以下であれば、ページで行われるすべてのインタラクションは確実に高速であると言えます。
redBus は、インドに拠点を置くバスの予約および乗車券販売のウェブサイトです。同社のウェブサイトの INP は、まだ試験運用版の指標と考えられていた時期でも、改善に尽力しました。こうした取り組みの結果、売上を 7% 伸ばすことに成功し、ウェブのパフォーマンスとビジネスの健全性の関連性を再び明確に示しました。redBus がウェブサイトの INP を改善するために行ったことをご紹介します。
上位の目標
redBus は、ウェブサイトの INP の最適化に着手したとき、次の 3 つの目標を掲げていました。
- ネットワーク速度やデバイスの性能に関係なく操作のレイテンシを重視することで、ユーザー エクスペリエンスを向上させます。
- ウェブサイトを最適化して、インタラクションをできるだけ速く維持する。
- フロントエンドへの高速データ転送を実現するために、API からのレスポンスをできる限り軽量化した。
プロセス
redBus はインタラクションのレイテンシを次の 2 つの方法に分類しました。
- クライアントで JavaScript をブロックすることで発生する操作レイテンシ。メインスレッドをブロックする JavaScript をインタラクションで過剰に使用すると、レンダリングが遅延し、ページの INP に影響します。
- API 呼び出しに起因するネットワーク レイテンシ。ネットワーク アクティビティは INP で測定されるものではありませんが、リモート API の呼び出しに依存するインタラクションは、低速なネットワークの場合や、リクエストのレスポンスが大きい場合に遅く感じられることがあります。
redBus は当初、自社のウェブサイトの INP は適切であると確信していましたが、この指標の 95 パーセンタイルの Real User Monitoring（RUM）データでは状況が異なります。
redBus による INP の測定方法
redBus は、Google が開発した web-vitals JavaScript ライブラリを利用して、ウェブサイトのすべてのページで INP だけでなく、重要なユーザー エクスペリエンス指標をすべてトラッキングしました。web-vitals JavaScript ライブラリに加えて、redBus は ELK を使用して、フロントエンドで収集された INP データを分析しました。
しかし、現場でウェブサイトの INP をトラッキングする方法は、redBus が問題にアプローチする方法とは大きく異なる可能性があります。インタラクションの最適化を開始する前に、フィールドで遅いインタラクションを見つける方法をお読みになり、ウェブサイトの INP を最適にトラッキングする方法と、ラボでそれらを再現する方法をお読みになることを強くおすすめします。
redBus は、INP を追跡するシステムを導入した後、データを分析して、遅いインタラクティビティが存在する場所をよりよく理解できるようになりました。
ユースケース
ユーザーが redBus のウェブサイトで運賃を検索する際は、検索ページで日付を変更して、目的地に合わせて選択した運賃をフィルタできます。このページの日付を変更する操作が遅く、これが INP の低下の原因となっていました。
また、ユーザーが運賃の一覧をスクロールすると、API から追加運賃が遅延読み込みされます。スクロール自体は INP の測定方法に考慮されませんが、scroll イベント リスナー自体は、メインスレッドで実行する必要がある多くの作業をスケジューリングします。この作業により、メインスレッドで競合が発生し、インタラクションのレイテンシが増加し、検索ページの INP が低下する原因となっていました。
redBus が検索ページの INP を最適化した方法
検索ページの INP を改善するために、redBus はいくつかの最適化を行いました。
scrollイベント ハンドラは、特定の期間内にイベント コールバックが呼び出される回数を減らすためにデバウンスされました。scrollイベント コールバックの実行頻度を下げることで、メインスレッドが検索ページでのユーザー操作により迅速に応答できるようになりました。- その結果得られたレンダリング処理は、
requestAnimationFrameコールバックを使用することで優先されていました。requestAnimationFrameは、コールバックの処理を次のフレームの前に完了する必要があることをブラウザに伝えます。
また、検索結果ページはさらに次のような最適化が行われました。
- 遅延読み込みを早期にトリガーすることで、ユーザー エクスペリエンスと視覚的なパフォーマンスを向上させるため、検索結果ページの最後から 2 番目のカードに結果の新しいバッチを取得しました。
- 遅延読み込みのたびに、各ネットワーク呼び出しで取得される結果が少なくなりました。フェッチを 30 から 10 に減らすことで、INP 範囲が 870 から 900 から 350 から 370 へと減少したことが観察されました。
これらの変更により検索ページの INP は大幅に改善されましたが、検索ページの入力フィールドの change イベントで高価なレデューサ関数を呼び出してユーザー インターフェースを更新するという問題が残っていました。その結果、ユーザー インターフェースが不必要に再レンダリングされ、ページの INP に影響が生じました。
このインタラクションを最適化するため、redBus は入力コンポーネントの状態をローカルで管理し、入力の blur イベントが発生したときにのみ Redux ストアと同期しました。この変更により、レデューサの呼び出し頻度を減らすことで、再レンダリングの回数を減らし、ユーザー インターフェースの不要な再レンダリングをなくしました。
この変更により、ページの INP が 72% 改善し、ユーザーが利用する可能性の高い、より高速でスムーズなユーザー エクスペリエンスが実現しました。
ビジネスへの影響
ビジネスの健全性とページ パフォーマンスの関係はよく知られています。INP は他の Core Web Vitals と比べて比較的新しい指標ですが、redBus は、この重要なユーザー中心のパフォーマンス指標の改善に重点を置くことで、優れたビジネス成果を観測しました。その結果、総売上が 7% 増加しました。
つまり、INP は redBus ウェブサイトにおけるランタイム パフォーマンスの問題の全体像を示すのに役立ちました。改善の余地があることを認識したうえで、redBus は問題を観察して再現し、その重要な情報を使用して redBus とそのビジネスにとって有益な最適化を行うことができました。