ウェブに関する主な指標の基準を突破し、直帰率を全体で 43% 向上させた Economic Times の事例

Economic Times のウェブサイトでウェブに関する主な指標を最適化することで、ユーザー エクスペリエンスが大幅に向上し、ウェブサイト全体の直帰率が大幅に低下しました。

Anshu Sharma
Anshu Sharma
Prashant Mishra
Prashant Mishra
Sumit Gugnani
Sumit Gugnani

インターネットの速度は日々改善されており、ウェブサイトはかつてないほどの速さで応答することを期待しています。The Economic Times は、1 か月のアクティブ ユーザー数が 4,500 万人を超えています。ドメイン全体で、AMP ページと非 AMP ページでウェブに関する主な指標を最適化することで、直帰率を大幅に削減し、読みやすさを改善することができました。

影響の測定

Google は、ユーザーに優れた読書体験を提供するうえで最も重要なことから、Largest Contentful Paint(LCP)Cumulative Layout Shift(CLS)に焦点を当てました。The Economic Times は、下記のようなさまざまなパフォーマンス修正の適用後、数か月のうちに Chrome ユーザーテスト(CrUX)レポートの指標を大幅に改善することに成功しました。

全体として、CLS は 0.25 から 0.09 に 250% 向上しました。 全体として、LCP は 4.5 秒から 2.5 秒へと 80% 向上しました

さらに、「低い」範囲の LCP 値は、2020 年 10 月から 2021 年 7 月までに 33% 減少しました。

2020 年 10 月から 2021 年 7 月までの LCP の分布を月別にグループ化したものです。「要改善」に分類された LCP 値は、15.03% から 10.08% に減少しました。

さらに、「低い」範囲の CLS 値が 65% 減少し、「良好」範囲の CLS 値が 20% 増加しています。

2020 年 10 月から 2021 年 7 月までの月別にグループ化された CLS の分布。「低い」と分類された CLS 値は、25.92% から 9%に減少、「良好」に分類された CLS 値は、62.62% から 76.5%に増加しました。

その結果、以前は Core Web Vitals のしきい値を満たしていなかった The Economic Times は、オリジン全体でウェブに関する主な指標の基準を満たすようになり、全体的な直帰率は 43% 減少しました。

Economic Times の記事ページのアニメーションの前後。

LCP の概要と改善方法

最大の要素は、ユーザー エクスペリエンスを向上させ、読み込み速度を認識するうえで最も関連性の高い要素です。First Contentful Paint(FCP)などのパフォーマンス指標では、ページの読み込み直後のエクスペリエンスのみが記録されます。一方、LCP は、ユーザーに表示される最も大きな画像、テキスト、動画セクションのレンダリング時間を報告します。

より高速な DNS プロバイダへの切り替えとイメージの最適化に加え、LCP を改善するために Google が適用した手法をいくつかご紹介します。

重大なリクエストを最初に

最新のブラウザはすべて同時リクエストの数を制限しているため、デベロッパーは重要なコンテンツを最初に読み込む必要があります。複雑なウェブページを読み込むには、ヘッダー要素、CSS、JavaScript リソース、ヒーロー画像、記事の本文、コメント、その他の関連ニュース、フッター、広告などのアセットをダウンロードする必要があります。LCP に必要な要素を評価し、LCP を改善するためにそれらのアイテムを最初に読み込むことを優先させました。また、最初のページ レンダリングに含まれない呼び出しも遅延させました。

テキストの外観

LCP と CLS の両方に影響する font-display プロパティを試しました。font-display: auto; を試してから font-display: swap; に切り替えました。これにより、テキストは最初に最適なフォントでレンダリングされ、ダウンロード後にフォントに切り替わります。その結果、ネットワークの速度に関係なく、テキストを高速でレンダリングできるようになりました。

優れた圧縮

Brotli は、Google が開発した Gzip および Deflate に代わる圧縮アルゴリズムです。フォントとアセットを置き換え、サーバー圧縮を Gzip から Brotli に変更し、フットプリントを縮小しました。

  • JavaScript ファイルは Gzip を使用する場合よりも 15% 小さくなります。
  • HTML ファイルは Gzip を使用する場合よりも 18% 小さくなります。
  • CSS ファイルとフォント ファイルは、Gzip を使用する場合よりも 17% 小さくなります。

サードパーティのドメインに事前接続する

preconnect は、特に安全な接続では、貴重な CPU 時間を消費したり、他の重要なリソースを遅延させたりする可能性があるため、慎重に使用する必要があります。

ただし、サードパーティのドメイン上のリソースを取得することがわかっている場合は、preconnect を使用するのがよいでしょう。トラフィックの多いウェブサイトでまれにしか発生しない場合は、preconnect によって不要な TCP および TLS 処理がトリガーされる可能性があります。そのため、事前に DNS ルックアップを実行するサードパーティ リソース(ソーシャル メディア、アナリティクスなど)には、dns-prefetch の方が適していました。

コードをチャンクに分割する

サイトのトップには、ビジネス ロジックの重要な部分を含むリソース、またはスクロールせずに見えるページのレンダリングに不可欠なリソースのみを読み込みました。さらに、コード分割によってコードをチャンクに分割します。これにより、ページの LCP をさらに改善することができました。

優れたキャッシュ保存

すべてのフロントエンド ルートに、キャッシュからテンプレートを提供する Redis レイヤを追加しました。これにより、サーバーでの計算時間が短縮され、各リクエストで UI 全体が構築されるため、後続のリクエストの LCP が減少します。

LCP の目標と実績の要約

最適化プロジェクトの開始前に、チームは LCP スコアを 4.5 秒(CrUX レポートのフィールド データに基づくユーザーの 75 パーセンタイル)とベンチマークしました。最適化プロジェクトの実施後は 2.5 秒に短縮されました。

2020 年 9 月から 2021 年 6 月までの LCP の分布。全体として、Chrome ユーザー エクスペリエンス レポートで観察された LCP 値の 75 パーセンタイルでは、LCP 値が「低速」で 8.97% 減少しました。75 パーセンタイルでの LCP 時間の全体的な減少は 200 ミリ秒で、LCP 値の 77.63% が「良好」範囲内に収まりました。
出典: 経済タイムズ全体 LCP の CrUX レポート

CLS の概要と改善方法

ウェブサイトを閲覧しているときに、ページ コンテンツの予期しない動きに気付いたことはありませんか?この問題の 1 つとして、ページ上のメディア(画像、動画、広告など)の非同期読み込みが、不明なサイズであることです。メディア リソースが読み込まれるとすぐに、ページのレイアウトがシフトします。

CLS を改善するための対策を The Economic Times のウェブサイトで紹介します。

プレースホルダを使用する

広告ライブラリでページ広告が読み込まれてレンダリングされる際のレイアウト シフトを避けるため、既知のサイズの広告ユニットとメディア要素にはスタイル付きのプレースホルダを使用しました。これにより、広告用のスペースが確保され、レイアウトの移動を回避できます。

スマートフォンで表示したエコノミクス タイムズのウェブサイトの比較。左側には、記事のヒーロー画像用に予約されているグレーのプレースホルダがあります。右側では、プレースホルダが読み込まれた画像に置き換えられます。

コンテナのディメンションの定義

すべての画像とコンテナに明示的なサイズを指定しているので、利用可能になるとブラウザ エンジンで DOM 要素の幅と高さを計算する必要がなくなります。これにより、不必要なレイアウト シフトや余分なペイント処理を回避できました。

CLS の目標と実績の要約

最適化プロジェクトを開始する前に、チームは CLS スコアのベンチマークを 0.25 としました。90%0.09 と大幅に減らすことができました。

Chrome ユーザー エクスペリエンス レポートに表示される CLS 分布CLS 値の 76% は「良い」、15% は「普通」、9% は「悪い」です。The Economic Times ウェブサイト全体のユーザー エクスペリエンスの 75 パーセンタイルでは、CLS は 0.09 でした。

初回入力遅延(FID)とは何ですか?また、どのように改善したのですか?

First Input Delay は、ユーザー入力に対するウェブサイトの応答性をトラッキングする指標です。FID スコアが低下する主な原因は、JavaScript の負荷が高く、ブラウザのメインスレッドをビジー状態に維持し、ユーザーの操作が遅れることです。FID はいくつかの方法で改善されました。

長い JavaScript タスクを分割する

長時間タスクとは、50 ミリ秒以上のタスクのことです。長いタスクはブラウザのメインスレッドを占有し、ユーザー入力に応答できなくなります。長時間実行されるタスクを、ユーザー リクエストに応じて可能な限り小さなタスクに分割することで、JavaScript の肥大化を軽減することができました。

Chrome の DevTools のパフォーマンス パネルに表示される、アクティビティ タイプ別に分類された CPU 時間。リソースの読み込みのスケジュール設定に 143 ミリ秒かかりました。JavaScript に 4,553 ミリ秒が費やされました。レンダリング処理に 961 ミリ秒が費やされました。ペイント オペレーションには 191 ミリ秒が費やされました。システムタスクでは 1,488 ミリ秒、アイドル時間は 3,877 ミリ秒。合計時間枠は 11,212 ミリ秒でした。

使用していない JavaScript を遅延させる

ページの応答性を高く維持するため、アナリティクスなどのサードパーティのスクリプトよりもページ コンテンツを優先しました。ただし、ユーザー ジャーニーを正確にトラッキングするためにドキュメント <head> に読み込む必要があるため、一部のライブラリには一定の制限があります。

ポリフィルを減らす

ブラウザが最新の API をサポートしており、従来のブラウザ(Internet Explorer など)を使用しているユーザーが減ったため、特定のポリフィルとライブラリへの依存を減らすことができました。

広告の遅延読み込み

スクロールしなければ見えない範囲の広告の遅延読み込みにより、メインスレッドのブロック時間を短縮し、FID を改善できました。

FID の目標と実績の要約

ルーチンのテストでは、現在では FID を 200 ミリ秒から 50 ミリ秒未満に短縮できました。

Chrome ユーザー エクスペリエンス レポートに表示される FID 分布。CLS 値の 86% は「良い」、10% は「普通」、4% は「悪い」です。The Economic Times ウェブサイト全体のユーザー エクスペリエンスの 75 パーセンタイルでは、FID は 44 ミリ秒でした。

回帰の防止

Economics Times は、ページ パフォーマンスの低下を避けるために、自動パフォーマンス チェックを本番環境に導入する予定です。ラボテストを自動化して本番環境ブランチでの回帰を防止するために、Lighthouse-CI を評価することを計画しています。