ページの Largest Contentful Paint（LCP）は改善が複雑な場合があり、多くの場合、複数の可動部分とトレードオフが伴います。この投稿では、ウェブ全体の実際のページ読み込みから得られるフィールド データを調べて、デベロッパーが最適化に注力すべき領域を判断しています。
LCP の古典的なアドバイスは、画像のサイズを小さくすることです。
ウェブ上のほとんどのページでは、LCP 要素は画像です。したがって、LCP を改善する最善の方法は、LCP 画像を最適化することであると考えるのは自然なことです。
LCP が導入されて約 5 年で、この点が主なアドバイスとしてよく流れてきました。画像は適切なサイズで、十分に圧縮されていることを確認し、その場で 21 世紀の画像形式を使用する。Lighthouse では、これらの提案を行うために、3 種類 の 監査も実施しています。
<ph type="x-smartling-placeholder">
<ph type="x-smartling-placeholder">これが一般的なアドバイスである理由の一つとして、過剰なバイト数は測定しやすく、画像圧縮ツールを提案しやすいことが挙げられます。ビルドとデプロイのパイプラインによっては、実装が簡単な場合もあります。
もしそうなら、実践してみましょう！ユーザーに送信するバイト数を少なくすると、ほとんどの場合はメリットがあります。ウェブ上には、基本的な圧縮で解決できるサイズを不必要に大きくしているサイトが多数存在します。
しかし、Chrome のユーザーがフィールド パフォーマンス データを調べ、LCP の時間がどこで費やされているのかを把握したところ、画像のダウンロード時間がボトルネックになることはほとんどないことがわかりました。
むしろ、LCP のその他の部分が大きな問題となっています。
LCP のサブパートの内訳
LCP の改善が見込める最大の分野を把握するために、LCP の最適化で説明したように、LCP の下位区分のデータを調べました。
ページの LCP 要素の読み込みと表示の方法は、ページとフレームワークによってそれぞれ異なりますが、各要素は次の 2 つの部分に分けることができます。
その記事を引用すると、サブパートは次のとおりです。
- Time to First Byte（TTFB）
- ユーザーがページの読み込みを開始してからブラウザが開くまでの時間 HTML ドキュメントのレスポンスの最初のバイトを受信する。
- リソース読み込みの遅延
- TTFB からブラウザが LCP リソースの読み込みを開始するまでの時間。条件
LCP 要素のレンダリングにリソースの読み込みは必要ありません。今回は
0です。 - リソースの読み込み時間
- LCP リソース自体の読み込みにかかる時間。LCP の
要素のレンダリングにリソースの読み込みは必要ありません。今回は
0です。 - 要素のレンダリングの遅延
- LCP リソースの読み込みが完了してから LCP 要素が表示されるまでの時間 完全にレンダリングされます。
実際のナビゲーションのパフォーマンス データ
| LCP 評価 | TTFB（ミリ秒） | 画像の読み込み遅延（ミリ秒） | 画像の読み込み時間（ミリ秒） | レンダリング遅延（ミリ秒） |
|---|---|---|---|---|
| 良い | 600 | 350 | 160 | 230 |
| 改善が必要 | 1,360 | 720 | 270 | 310 |
| 悪い | 2,270 人 | 1,290 | 350 | 360 |
この投稿では、Chrome でサブリソース イメージ LCP があるページ ナビゲーションのデータを使用して、LCP のサブパートを確認しました。このようなデータは以前にも確認しましたが、フィールド データからは、ページの 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 全体で潜在的なミリ秒単位で向上する可能性はわずかであることは明らかです。
<ph type="x-smartling-placeholder">そして最後に、読み込み時間の遅延は、モバイル デバイスとモバイル ネットワークの品質が原因となっていたことが多くあります。かつては、一般的なスマートフォンでは、有線接続したデスクトップ マシンと同じ画像をダウンロードするのに何倍もの時間がかかると思っていたかもしれません。データによると、もはや事実ではありません。LCP が低いオリジンの場合、モバイルではパソコンよりも p75 画像の読み込み時間の中央値がわずか 20% しか遅くありません。
Time to First Byte（TTFB）
ネットワーク リクエストを行うナビゲーションの場合、TTFB には常に時間がかかります。DNS ルックアップを行って接続を開始するのに時間がかかります。物理学に勝ることはできません。リクエストは、ワイヤーや光ケーブルを介して現実世界を通ってサーバーに到達し、レスポンスによって元の場所に戻る必要があります。LCP が良好であるオリジンの中央値でさえ、75 パーセンタイルで TTFB に 0.5 秒以上かかっています。
ただし、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 秒となっています。これは、1 つのサブパートで消費される 2.5 秒の LCP 予算の半分以上に相当します。
読み込み遅延が長くなる一般的な原因は、依存関係チェーンです。よりシンプルなのは、ページがスタイルシートを読み込むことです。スタイルシートは、ブラウザがレイアウトを行った後で、最終的な LCP となる背景画像を設定します。これらのステップはすべて、ブラウザが LCP 画像のダウンロードを開始することを認識する前に実行する必要があります。
「開始者」を記録する HTTP Archive 公開クロールデータを使用するHTML ドキュメントから LCP 画像へのネットワーク リクエストのチェーンにより、リクエスト チェーンの長さと遅い LCP の明確な相関関係がわかります。
<ph type="x-smartling-placeholder">
<ph type="x-smartling-placeholder">重要なのは、LCP の内容をできるだけ早くブラウザに通知して、ページのレイアウト内に 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 のサブパートをローカルでテストするには、Web Vitals 拡張機能またはこの記事の JavaScript スニペットをお試しください。Lighthouse では、「Largest Contentful Paint 要素」に内訳も表示されます。監査をご覧ください。DevTools の [Performance] パネルで、LCP のサブパートに関する他のアドバイスを確認します（近日提供予定）。