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