INP の修正に関する Economic Times のクエスト

TBT を 30 分の 1 削減と Next.js への移行により、The Ecomonic Times は INP を約 4 回削減し、直帰率が 50% 減少し、ページビュー数が 43% 増加しました。

ダヤ・ラム・ヤダブ
Daya Ram Yadav 氏
Saurabh Rajpal 氏
Saurabh Rajpal

Interaction to Next Paint(INP)は、ユーザー入力に対するウェブサイトの応答性を評価する指標です。応答性が良いとは、ページでユーザーの操作にすばやく反応することを意味します。ページの INP が低いほど、ユーザーの操作に適切に応答できます。

適切な INP 値は 200 ミリ秒以下、低い値は 500 ミリ秒を超え、その間はすべて改善が必要です。

あいまいな始まり

ウェブに関する主な指標の一つに進化する可能性を秘めた試験運用版指標として Google が最初に INP を導入したとき、Economy Times チームは、世界クラスのユーザー エクスペリエンスを提供することが Google のコアビジネス価値にとって極めて重要であるため、1 つに昇格する前に修正するという課題に取り組みました。

INP は、これまで解決するのが最も難しい指標の一つです。当初は、INP を効果的に測定する方法が不明確でした。この問題をより困難にしたのは、コミュニティ・サポートの欠如でした。これには、ほとんどのリアル・ユーザー・モニタリング(RUM)プロバイダーがまだサポートしていません。しかし、Chrome ユーザー エクスペリエンス レポート(CrUX)web-vitals JavaScript ライブラリなどの Google RUM ツール、およびそれをサポートする他のツールがあったため、今後の方向性を評価する際の立ち位置を知ることができました。開始時の INP は、オリジン レベルで 1,000 ミリ秒近くでした。

フィールドで INP を修正する際に浮かび上がったことの一つは、ターゲットとするラボ指標の 1 つが Total Blocking Time(TBT)であったということです。TBT はすでに十分に文書化され、コミュニティによってサポートされていました。しかし、ウェブに関する主な指標のしきい値はすでに満たしていますが、開始時点では 3 秒を超えていたため、TBT についてはまだ改善の余地がありました。

TBT の概要と改善策

TBT は、ページの読み込み時のユーザー入力に対するウェブページの応答性を測定するラボの指標です。実行に 50 ミリ秒を超える時間を要するタスクは長時間のタスクとみなされ、50 ミリ秒のしきい値を超えた時間はブロッキング時間と呼ばれます。

TBT は、ページ読み込み中のすべての長いタスクのブロック時間の合計で計算されます。たとえば、読み込み中に長いタスクが 2 つある場合、ブロック時間は次のように決定されます。

  • タスク A には 80 ミリ秒(50 ミリ秒より 30 ミリ秒)かかります。
  • タスク B には 100 ミリ秒(50 ミリ秒より 50 ミリ秒)かかります。

ページの TBT は 80 ミリ秒(30 + 50)になります。TBT は低いほど良く、TBT も INP とよく相関しています

以下に、TBT の改善前と実施後の簡単なラボ比較を示します。

Chrome DevTools のパフォーマンス パネルに表示されている起動中の長時間タスクの合成画像と、ページ指標のレポート。ページ読み込み中にメインスレッドが 3,260 ミリ秒ブロックされます。
TBT を最適化する前の起動時のメインスレッド。TBT は 3,260 ミリ秒です。
Chrome DevTools のパフォーマンス パネルに表示されている起動中の長時間タスクの合成画像と、ページ指標のレポート。メインスレッドはページの読み込み中に 120 ミリ秒ブロックされます。
TBT の最適化後の起動時のメインスレッド。TBT は 120 ミリ秒です。

メインスレッドの作業を最小限に抑える

ブラウザのメインスレッドは、HTML の解析、DOM の構築、CSS の解析とスタイルの適用、JavaScript の評価と実行など、すべての処理を行います。メインスレッドは、クリック、タップ、キー操作などのユーザー操作も処理します。メインスレッドが他の処理に専念すると、ユーザー入力に効率的に応答できず、ユーザー エクスペリエンスのジャンクにつながる可能性があります。

定期購入のステータスに基づいて広告を配信するユーザー ID を検出する独自のアルゴリズムと、A/B テストや分析などのサードパーティ製スクリプトを使用する独自のアルゴリズムがあるため、これは当社にとって最も困難なタスクでした。

最初は、重要性の低いビジネス アセットの読み込みの優先度を下げるなどの小さな対策を講じました。次に、重要度の低い作業に requestIdleCallback を使用しました。これは TBT の削減に役立ちます。

if ('requestIdleCallback' in window) {
  this.requestIdleCallbackId = requestIdleCallback(fetchMarketsData.bind(this), {timeout: 3000});
} else {
  fetchMarketsData(); // Fallback in case requestIdleCallback is not supported
}

requestIdleCallback を使用する場合は、タイムアウトの指定をおすすめします。指定した時間が経過してもコールバックがまだ呼び出されていない場合、タイムアウトの直後にコールバックが実行されます。

スクリプトの評価時間を最小限に抑える

また、ローダブル コンポーネントを使用して、サードパーティ ライブラリを遅延読み込みしました。また、Chrome DevTools のカバレッジ ツールを使用してページをプロファイリングすることで、使用されていない JavaScript と CSS を削除しました。これにより、ツリー シェイキングが必要な領域を特定し、ページの読み込み時に送信するコードを減らし、アプリケーションの初期バンドルサイズを削減できました。

Chrome DevTools のカバレッジ ツールのスクリーンショット。ここでは、ページの読み込み中に JavaScript ファイルと CSS ファイルの未使用部分を表示します。

DOM サイズを縮小する

Lighthouse によると、DOM サイズが大きいとメモリ使用量が増加し、スタイルの再計算が長くなり、レイアウト リフローのコストも増大します。

Lighthouse での DOM サイズ監査のスクリーンショット。レポートされる DOM 要素の数は 2,706 です。

次の 2 つの方法で DOM ノードの数を少なくしました。

  • まず、ユーザーのリクエスト(クリック時)に応じてメニュー項目をレンダリングしました。その結果、DOM のサイズが約 1,200 ノード削減されました。
  • 次に、重要性の低いウィジェットを遅延読み込みしました。

こうしたさまざまな取り組みの結果、TBT を大幅に削減し、それに応じて INP を約 50% 削減しました。

CrUX での INP 監査のスクリーンショット。ページの INP は 539 ミリ秒で、「低速」のしきい値を超えています。

この時点で、TBT(およびプロキシごとの INP)をさらに削減するための簡単な成果はほぼなくなりましたが、改善の余地がたくさんあることがわかりました。そこで、カスタムビルドの UI ボイラープレートを、Next.js とともに React の最新バージョンにアップグレードすることにしました。これにより、フックを活用してコンポーネントの不要な再レンダリングを回避できます。

ウェブサイトの他の部分に比べて更新頻度が高く、トラフィックが比較的少ないことから、トピックページの Next.js への移行を開始しました。また、負荷の高いメインスレッドの作業をウェブ ワーカーにオフロードするために PartyTown を使用するとともに、重要性の低いタスクを遅らせる requestIdleCallBack などの手法も使用しました。

INP の改善は、The Economic Times にどのように役立っていますか?

現在のオリジンの TBT と INP

この投稿を公開した時点では、オリジンの TBT は 120 ミリ秒で、最適化の取り組みを開始したときの 3,260 ミリ秒から低下しました。同様に、オリジンの INP は、最適化の取り組み後 257 ミリ秒となり、1,000 ミリ秒を超えていました。

CrUX での INP 監査のスクリーンショット。ページの INP は 257 ミリ秒で、「改善が必要」のしきい値の範囲内です。

INP CrUX の傾向

トピックページで受信するトラフィックは、全体のトラフィックに占める割合が非常に少ないものです。そのため、テストを行うのに理想的な場所でした。CrUX の結果とビジネスの成果は非常に励みとなり、さらなるメリットを享受するために、ウェブサイト全体に取り組みを拡大することができました。

2022 年 7 月から 2022 年 10 月までの 4 か月間の INP 分布を CrUX で可視化したスクリーンショット。「低い」と「改善が必要」のしきい値内の値はやや低下し、「良好」のしきい値内の値は増加しています。

Akamai mPulse TBT 分析

現場の TBT を測定する RUM ソリューションとして Akamai mPulse を使用しています。TBT は一貫して減少しており、INP を削減する取り組みの成果と明確にマッピングされています。次のスクリーンショットからわかるように、TBT 値はフィールドで最終的に約 5 秒から約 200 ミリ秒に低下しました。

Akamai mPulse のグラフのスクリーンショット。約 1 か月間で TBT が減少しています。

ビジネス上の成果

全体として、TBT を 30 倍に削減し、Next.js に移行すると、INP を約 4 倍に減らすことができました。その結果、トピックページの直帰率が 50% 減少し、ページビュー数が 43% 増加しました

ページビュー数と直帰率を比較した Google アナリティクスのスクリーンショット。The Economic Times のウェブサイトで INP が最適化された結果、直帰率が 50% 減少し、ページビュー数が 43% 増加しました。

まとめ

まとめると、INP は、Economy Times ウェブサイトの一部でランタイム パフォーマンスの問題の特定に幅広く貢献しました。ビジネスの成果にプラスの影響を与える最も効果的な指標の 1 つであることが証明されています。この取り組みの結果、非常に励みになる数字が見られたことから、最適化の取り組みをウェブサイトの他の領域にも拡大し、さらなるメリットを享受したいと私は思っています。