LCP の最適化方法に関するよくある誤解

ページの Largest Contentful Paint(LCP)を改善するのは複雑な作業になることがあります。多くの場合、複数の要素やトレードオフが関係します。この記事では、ウェブ全体の実際のページ読み込みから得られたフィールドデータを調べ、デベロッパーが最適化に注力すべき場所を特定します。

ウェブ上のほとんどのページでは、LCP 要素は画像です。そのため、LCP を改善する最善の方法は、LCP 画像を最適化することであると推測するのは自然なことです。

LCP が導入されてから 5 年ほどの間に、このアドバイスがよく見られました。画像のサイズが適切で、十分に圧縮されていることを確認します。また、21 世紀の画像形式を使用することをおすすめします。Lighthouse には、こうした改善案を提示する3 つの 異なる 監査があります。

Lighthouse レポートの 3 つの画像最適化監査
Lighthouse レポートの 3 つの画像最適化監査。

これが一般的なアドバイスである理由の 1 つは、バイト数の超過は簡単に測定でき、画像圧縮ツールを簡単に提案できることです。ビルド パイプラインとデプロイ パイプラインによっては、実装が簡単な場合もあります。

ある場合は、ぜひお試しください。ユーザーに送信するバイト数を減らすことは、ほとんどの場合メリットがあります。ウェブ上には、基本的な圧縮でも解決できる、不必要に大きな画像を配信しているサイトが数多くあります。

しかし、Chrome ユーザーのフィールド パフォーマンス データを調べて、LCP までの時間の多くがどこで費やされているかを確認した結果、画像のダウンロード時間がボトルネックになることはほとんどないことがわかりました。

むしろ、LCP の他の部分の方がはるかに大きな問題です。

LCP のサブパートの内訳

LCP を改善するための最大の機会領域を把握するため、LCP を最適化するで説明されているように、LCP のサブパートのデータを確認しました。

ページやフレームワークによって、ページの LCP 要素となる要素の読み込みと表示方法は異なりますが、いずれも次のサブパーツに分けることができます。

4 つのサブパートを示す LCP の内訳

その記事から引用すると、サブパートは次のとおりです。

Time to First Byte(TTFB)
ユーザーがページの読み込みを開始してから、ブラウザが HTML ドキュメント レスポンスの最初のバイトを受信するまでの時間。
リソース読み込みの遅延
TTFB からブラウザが LCP リソースの読み込みを開始するまでの時間。LCP 要素のレンダリングにリソースの読み込みが不要な場合、この時間は 0 です。
リソースの読み込み時間
LCP リソース自体の読み込みにかかる時間。LCP 要素のレンダリングにリソースの読み込みが不要な場合、この時間は 0 です。
要素のレンダリングの遅延
LCP リソースの読み込みが完了してから、LCP 要素のレンダリングが完了するまでの時間。

実際のナビゲーションのパフォーマンス データ

各 LCP サブパートの所要時間の差異を可視化した棒グラフ。LCP バケット(良好、改善が必要、低速)ごとにグループ化されています。TTFB と読み込み遅延の時間が急激に長くなる一方で、読み込み時間とレンダリング遅延は短いままです。データは次の表に示されています。

LCP の評価 TTFB(ミリ秒) 画像の読み込み遅延(ミリ秒) 画像の読み込み時間(ミリ秒) レンダリングの遅延(ミリ秒)
良い 600 350 160 230
改善が必要 1,360 720 270 310
悪い 2,270 1,290 350 360

この記事では、Chrome のサブリソース画像 LCP を含むページ ナビゲーションのデータを使用して、LCP のサブパートについて説明します。Google は以前にもこの種のデータを確認したことがありますが、フィールド データから、実際のユーザーがページの LCP を待っている間にどこに時間を費やしているかを把握したことはありませんでした。

Core Web Vitals と同様に、CrUX データセット内の各オリジンの各 LCP サブパートの 75 パーセンタイル(p75)を取得し、p75 値の 4 つの分布(サブパートごとに 1 つ)を作成しました。これらの分布を要約するために、4 つの LCP サブパートのそれぞれについて、すべてのオリジンにわたる値の中央値を算出しました。

最後に、75 パーセンタイル時の LCP が「良好」、「改善が必要」、「低速」のいずれであるかに基づいてオリジンをバケットに分割します。これにより、LCP が良好なオリジンと LCP が低いオリジンの違いを把握できます。

LCP 画像のサイズを小さくする。今回はデータあり

読み込み時間は、LCP リソース(この場合は画像)を取得するのにかかる時間の測定値です。この時間は通常、画像のバイト数に比例するため、バイト数を減らすようパフォーマンスに関するアドバイスが提示されます。

上のグラフで時間の流れを確認すると、画像の読み込みに時間がかかっていないことがわかります。実際、これはすべての LCP バケットの中で最も短い LCP サブパートです。LCP が遅いオリジンでは読み込み時間が長くなりますが、それでも時間の大部分が費やされる場所ではありません。

LCP が低いオリジンのほとんどは、p75 LCP 時間の 10% 未満を LCP 画像のダウンロードに費やしています。

はい。画像を最適化する必要がありますが、これは LCP を改善するための手段の一つにすぎません。このデータから明らかなように、ウェブ上の一般的なオリジンでは、圧縮スキームがどれほど高度であっても、LCP の全体的なミリ秒単位の短縮はわずかです。

最後に驚くべき事実をご紹介します。読み込み時間が遅い原因は、かつては通常、モバイル デバイスとモバイル ネットワークの品質にありました。かつては、一般的なスマートフォンで、デスクトップ マシンと同じ画像を有線接続でダウンロードするのに、数倍の時間がかかると思われていました。しかし、データはそうではないことを示しています。LCP が低速なオリジンの場合、モバイルでの画像読み込み時間の中央値(p75)は、パソコンと比べてわずか 20% 遅くなります。

Time to First Byte(TTFB)

ネットワーク リクエストを行うナビゲーションの場合、TTFB には常に時間がかかります。DNS ルックアップと接続の開始には時間がかかります。物理的な制約もあります。リクエストはワイヤーや光ファイバーケーブルを介して現実世界を移動してサーバーに到達し、レスポンスは戻ってくる必要があります。LCP が良好なオリジンの中央値でも、TTFB の 75 パーセンタイルでは半秒を超えています。

ただし、LCP のオリジンが良好なページと不十分なページの間で TTFB に差異がある場合は、改善の余地があることを示しています。LCP が低いオリジンの少なくとも半分については、p75 TTFB が 2,270 ミリ秒のみで、p75 LCP が「良好」の基準である 2.5 秒より速くなることはほぼありません。この時間を少しでも短縮できれば、LCP が大幅に改善されます。

物理の法則を打ち破ることはできないかもしれませんが、できることはあります。たとえば、ユーザーがサーバーとは非常に異なる場所にいることが多い場合は、CDN を使用してコンテンツをユーザーの近くに配置できます。

詳しくは、TTFB の最適化ガイドをご覧ください。

リソース読み込みの遅延: 見落とされがちな LCP の遅延の原因

TTFB を改善できるものの、改善が物理的な制約によって制限されている場合は、リソースの読み込み遅延を排除できる可能性があります。実際には、サービング アーキテクチャによってのみ制限されます。

このサブパートでは、HTML レスポンスの最初のバイトが到着してから(TTFB)、ブラウザが LCP 画像のリクエストを開始するまでの時間を測定します。Google は長年にわたり、LCP 画像のダウンロードにかかる時間に重点を置いてきましたが、ブラウザがダウンロードを開始するまでに無駄に費やされる時間については、ほとんど無視してきました。

LCP が低いサイトの中央値は、LCP 画像のダウンロードを開始するまでに、実際にダウンロードする時間のほぼ 4 倍の時間を費やしています。TTFB と画像リクエストの間に 1.3 秒の待ち時間があります。つまり、2.5 秒の LCP 予算の半分以上が 1 つのサブパートで消費されたことになります。

読み込みに時間がかかる原因として、依存関係チェーンがよく挙げられます。シンプルな例としては、スタイルシートを読み込むページがあります。このページでは、ブラウザがレイアウトを行った後に、LCP となる背景画像が設定されます。ブラウザが LCP 画像のダウンロードを開始する前に、これらのステップをすべて完了する必要があります。

HTTP Archive のパブリック クロールデータ(HTML ドキュメントから LCP 画像へのネットワーク リクエストの「イニシエーター」チェーンを記録)を使用すると、リクエスト チェーンの長さと LCP の遅延との間に明確な相関関係があることがわかります。

依存するリクエスト チェーンと LCP の関係を可視化したグラフ。LCP の中央値は、依存リクエストが 0 件の場合 2,150 ミリ秒、1 件の場合 2,540 ミリ秒、2 件の場合 2,850 ミリ秒に増加します。
依存リクエスト チェーンと LCP の関係。

重要なのは、LCP が何であるかをできるだけ早くブラウザに知らせ、ページのレイアウトに表示する場所が用意される前でも読み込みを開始できるようにすることです。これを実現するために利用できるツールはいくつかあります。たとえば、プリロード スキャナがすぐに見つけられるように HTML に従来の <img> タグを配置してダウンロードを開始したり、<img> ではない画像に <link rel="preload"> タグ(または HTTP ヘッダー)を配置したりします。

また、優先するリソースをブラウザが判断できるようにすることも重要です。これは、ページの読み込み中にページが大量のリクエストを実行している場合に特に当てはまります。多くの場合、ブラウザは、それらのリソースの多くが読み込まれてレイアウトが完了するまで、LCP 要素が何であるかを把握できません。可能性のある LCP 要素に fetchpriority="high" 属性をアノテーションすると(loading="lazy" は使用しないでください)、ブラウザにリソースの読み込みをすぐに開始するよう明示できます。

読み込み遅延の最適化に関するその他のアドバイスをご覧ください。

レンダリング遅延

レンダリング遅延は、ブラウザが LCP イメージを読み込んで準備が整い、なんらかの理由で画面に表示されるまでの時間です。画像の準備が整ったときにメインスレッドをブロックする長いタスクである場合もあれば、非表示の要素を表示する UI の選択である場合もあります。

ウェブ上の一般的なオリジンでは、レンダリングの遅延を大きく減らす余地はないように思えますが、最適化中に、他のサブパーツで費やされていた時間をレンダリングの遅延に割り当てることがあります。たとえば、ページが LCP 画像のプリロードを開始してすぐに使用できるようにすると、長い読み込み遅延は発生しなくなりますが、ページ自体が画像を表示する準備ができていない場合は(レンダリングをブロックする大きなスタイルシートや、表示する前にすべての JavaScript の読み込みを完了する必要があるクライアントサイド レンダリング アプリなど)、LCP は想定よりも遅くなり、待機時間はレンダリング遅延として表示されます。そのため、LCP に関しては、サーバーサイド レンダリングや静的 HTML が有利な場合が多いです。

お客様のコンテンツが影響を受けている場合は、レンダリング遅延の最適化に関するその他のアドバイスをご覧ください。

すべてのサブパーツを確認する

LCP を効果的に最適化するには、画像の最適化だけでなく、ページの読み込み全体を総合的に検討することが必要であることは明らかです。LCP までの時間のすべての部分を確認します。改善の余地が非常に大きい可能性があります。

現場でこのデータを収集するため、web-vitals ライブラリのアトリビューション ビルドには LCP のサブパートのタイミングが含まれています。Chrome ユーザー エクスペリエンス レポート(CrUX)には、まだこれらのデータがすべて含まれているわけではありませんが、TTFB と LCP のエントリは含まれているため、まずはこれを利用できます。今後、この投稿で使用したデータを CrUX に含める予定です。最新情報をお待ちください。

LCP のサブパートをローカルでテストするには、ウェブに関する主な指標拡張機能またはこの記事の JavaScript スニペットをお試しください。Lighthouse では、「最大コンテンツの描画」要素の監査に内訳も含まれます。LCP のサブパートに関するその他のアドバイスについては、近日提供予定の DevTools の [パフォーマンス] パネルをご覧ください。