TBT を 30 倍に短縮し、Next.js に移行したことで、The Ecomonic Times は INP を 4 倍近く削減し、離脱率を 50% 低減、ページビューを 43% 増加させました。
Interaction to Next Paint（INP）は、ユーザー入力に対するウェブサイトの応答性を評価する指標です。応答性が良好とは、ページがユーザー操作に迅速に応答することを意味します。ページの INP が低いほど、ユーザー操作に応答しやすくなります。
曖昧な始まり
Google が INP を、Core Web Vitals の指標の 1 つに進化する可能性のある試験運用版の指標として最初に導入したとき、Economic Times チームは、世界クラスのユーザー エクスペリエンスを提供することがコアなビジネス価値にとって重要であるため、Core Web Vitals の指標に昇格する前に INP を修正するという課題に取り組みました。
INP はこれまで最も解決が難しい指標の一つでした。当初は、インプレッション数を効果的に測定する方法が不明確でした。コミュニティ サポートの欠如も問題でした。ほとんどのリアルユーザー モニタリング（RUM）プロバイダがまだサポートしていないなどです。ただし、Chrome ユーザー エクスペリエンス レポート（CrUX）や web-vitals JavaScript ライブラリなどの Google RUM ツールがあり、それらを活用することで、今後の方向性を評価しながら、現状を把握することができました。開始当初、オリジン レベルでの INP は 1,000 ミリ秒近くでした。
現場で INP を修正する際に判明した点として、ターゲットとするラボ指標の 1 つとして Total Blocking Time（TBT）が考えられます。TBT はすでに十分に文書化され、コミュニティによってサポートされていました。ウェブに関する主な指標のしきい値はすでに満たしていましたが、TBT については、開始時点で 3 秒を超えていたため、状況は良くありませんでした。
TBT とは何ですか？また、改善のためにどのような措置を講じましたか？
TBT は、ページの読み込み中のユーザー入力に対するウェブページの応答性を測定するラボ指標です。実行に 50 ミリ秒を超えるタスクはすべて長いタスクと見なされ、50 ミリ秒のしきい値を超えた時間はブロック時間と呼ばれます。
TBT は、ページ読み込み中のすべての長いタスクのブロック時間を合計して計算されます。たとえば、読み込み中に 2 つの長いタスクがある場合、ブロック時間は次のように決定されます。
- タスク A に 80 ミリ秒（50 ミリ秒より 30 ミリ秒）かかる。
- タスク B は 100 ミリ秒（50 ミリ秒より 50 ミリ秒長い）かかります。
ページの TBT は 80 ミリ秒（30 + 50）になります。TBT は短いほど良好であり、TBT も INP とよく相関しています。
改善策を講じた前後の TBT をラボで簡単に比較した結果は次のとおりです。
メインスレッドの作業を最小限に抑える
ブラウザのメインのスレッドは、HTML の解析、DOM の構築、CSS の解析とスタイルの適用、JavaScript の評価と実行など、すべてを処理します。メインスレッドは、ユーザー操作（クリック、タップ、キー入力）も処理します。メインスレッドが他の処理を占有している場合、ユーザー入力に効率的に応答せず、ユーザー エクスペリエンスのジャンクにつながる可能性があります。
これは Google にとって最も困難なタスクでした。Google には、定期購入のステータスや、A/B テストや分析用のサードパーティ スクリプトに基づいて広告を配信するためのユーザー ID を検出する独自のアルゴリズムがあるためです。
最初は、重要度の低いビジネス アセットの読み込みを優先順位から外すなど、小さなステップから始めました。2 つ目は、クリティカルでない作業に 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 を削除しました。これにより、ページの読み込み時にコードを削減してアプリケーションの初期バンドルサイズを小さくするためにツリー シェイキングが必要な領域を特定できました。
DOM サイズを小さくする
Lighthouse によると、DOM サイズが大きいと、メモリの使用量が増え、スタイルの再計算に時間がかかり、レイアウトのリフローというコストが発生します。
DOM ノードの数を次の 2 つの方法で削減しました。
- まず、ユーザーのリクエスト（クリック）に応じてメニュー アイテムをレンダリングしました。これにより、DOM のサイズが約 1,200 ノード削減されました。
- 次に、重要性の低いウィジェットを遅延読み込みしました。
こうした取り組みの結果、TBT は大幅に削減され、それに伴い INP も約 50% 削減されました。
この時点で、TBT（およびプロキシによる INP）をさらに削減するための簡単な方法はほとんど残っていませんでしたが、改善の余地はまだまだあるとわかっていました。そこで、フックをより活用し、コンポーネントの不要な再レンダリングを回避するために、カスタムビルドの UI ボイラープレートを最新バージョンの React と Next.js にアップグレードすることにしました。
ウェブサイトの他の部分と比べて更新の頻度が高く、トラフィックが比較的少ないため、トピックページを Next.js への移行を開始しました。また、PartyTown を使用して、メインスレッドの負荷の高い処理を Web Worker にオフロードし、requestIdleCallBack などの手法で重要でないタスクを遅らせました。
INP の改善が The Economic Times にどのような効果をもたらしたか
送信元の現在の TBT と INP
この投稿を公開した時点で、オリジンの TBT は 120 ミリ秒で、最適化の取り組みを開始したときの 3,260 ミリ秒から減少しました。同様に、最適化後、オリジンの INP は 1,000 ミリ秒超から 257 ミリ秒に低下しました。
INP CrUX の傾向
トピック ページで獲得したトラフィックは、全体的なトラフィックのごく一部に過ぎません。そのため、テストを行うのに最適な場所でした。CrUX の結果とビジネス成果は非常に好調で、さらなる成果を得るためにウェブサイト全体に取り組みを拡大しました。
Akamai mPulse TBT 分析
Google は RUM ソリューションとして Akamai mPulse を使用しており、フィールドで TBT を測定しています。TBT は着実に減少しており、これは INP 削減に向けた取り組みの成果と明確に関連しています。以下のスクリーンショットからわかるように、TBT 値は最終的にフィールドの約 5 秒から約 200 ミリ秒に低下しました。
ビジネス上の成果
全体として、TBT を 30 分の 1 に短縮する取り組みと Next.js への移行により、INP は約 4 分の 1 に削減され、最終的にトピックページの直帰率が 50% 低下し、ページビューが 43% 増加しました。
まとめ
要約すると、INP は Economic Times ウェブサイトの一部で発生しているランタイム パフォーマンスの問題の特定に大きく貢献しました。ビジネス成果にプラスの影響を与える最も効果的な指標の一つであることが実証されています。この取り組みの結果、非常に好ましい数値が得られたことを受けて、ウェブサイトの他の領域にも最適化の取り組みを拡大し、さらなる成果を得ようとしています。