TBT を 30 分の 1 削減と Next.js への移行により、The Ecomonic Times は INP を約 4 回削減し、直帰率が 50% 減少し、ページビュー数が 43% 増加しました。
Interaction to Next Paint（INP）は、ユーザー入力に対するウェブサイトの応答性を評価する指標です。応答性が良いとは、ページでユーザーの操作にすばやく反応することを意味します。ページの INP が低いほど、ユーザーの操作に適切に応答できます。
あいまいな始まり
ウェブに関する主な指標の一つに進化する可能性を秘めた試験運用版指標として 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 の改善前と実施後の簡単なラボ比較を示します。
メインスレッドの作業を最小限に抑える
ブラウザのメインスレッドは、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 サイズが大きいとメモリ使用量が増加し、スタイルの再計算が長くなり、レイアウト リフローのコストも増大します。
次の 2 つの方法で DOM ノードの数を少なくしました。
- まず、ユーザーのリクエスト（クリック時）に応じてメニュー項目をレンダリングしました。その結果、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 は、最適化の取り組み後 257 ミリ秒となり、1,000 ミリ秒を超えていました。
INP CrUX の傾向
トピックページで受信するトラフィックは、全体のトラフィックに占める割合が非常に少ないものです。そのため、テストを行うのに理想的な場所でした。CrUX の結果とビジネスの成果は非常に励みとなり、さらなるメリットを享受するために、ウェブサイト全体に取り組みを拡大することができました。
Akamai mPulse TBT 分析
現場の TBT を測定する RUM ソリューションとして Akamai mPulse を使用しています。TBT は一貫して減少しており、INP を削減する取り組みの成果と明確にマッピングされています。次のスクリーンショットからわかるように、TBT 値はフィールドで最終的に約 5 秒から約 200 ミリ秒に低下しました。
ビジネス上の成果
全体として、TBT を 30 倍に削減し、Next.js に移行すると、INP を約 4 倍に減らすことができました。その結果、トピックページの直帰率が 50% 減少し、ページビュー数が 43% 増加しました。
おわりに
まとめると、INP は、Economy Times ウェブサイトの一部でランタイム パフォーマンスの問題の特定に幅広く貢献しました。ビジネスの成果にプラスの影響を与える最も効果的な指標の 1 つであることが証明されています。この取り組みの結果、非常に励みになる数字が見られたことから、最適化の取り組みをウェブサイトの他の領域にも拡大し、さらなるメリットを享受したいと私は思っています。