LCP を分類して主な改善点を特定する手順ガイドです。
Largest Contentful Paint(LCP)は Core Web Vitals の 3 つの指標のうちの一つで、ウェブページのメイン コンテンツの読み込み速度を表します。具体的には、LCP はユーザーがページの読み込みを開始してから、最大の画像やテキスト ブロックがビューポート内にレンダリングされるまでの時間を測定します。
優れたユーザー エクスペリエンスを提供するには、サイトへのアクセスの 75% 以上で LCP を 2.5 秒以下にする必要があります。
ブラウザでのウェブページの読み込みとレンダリングの速度にはさまざまな要因が影響し、どれかひとつの遅延が LCP に重大な影響を及ぼします。
ページのごく一部を短時間で修正しても、LCP が大幅に改善されることはめったにありません。LCP を改善するには、読み込みプロセス全体を確認し、すべてのステップを最適化する必要があります。
LCP 指標について
LCP を最適化する前に、デベロッパーは LCP の問題があるかどうか、またそのような問題の程度を把握する必要があります。
LCP はさまざまなツールで測定できますが、これらすべてのツールで同じ方法で LCP を測定するわけではありません。実際のユーザーの LCP を把握するには、Lighthouse などのラボベースのツールやローカルテストで示される内容ではなく、実際のユーザーの状況に着目する必要があります。これらのラボベースのツールは、LCP の説明や改善に役立つ豊富な情報を提供しますが、ラボテストだけでは実際のユーザー エクスペリエンスを完全に表していない可能性があるので注意してください。
実際のユーザーに基づく LCP データは、サイトにインストールされた Real User Monitoring(RUM)ツールや、何百万ものウェブサイトの実際の Chrome ユーザーから匿名データを収集する Chrome ユーザー エクスペリエンス レポート(CrUX)を使用して確認できます。
PageSpeed Insights CrUX LCP データを使用する
PageSpeed Insights では、一番上のセクションの [実際のユーザー エクスペリエンスを調べる] から CrUX のデータにアクセスできます。ラボベースのより詳細なデータは、下部の [パフォーマンスの問題を診断する] というセクションで確認できます。ウェブサイトで CrUX データを利用できる場合は、必ず実際のユーザーデータに注目してください。
PageSpeed Insights には、最大 4 種類の CrUX データが表示されます。
- この URL のモバイルデータ
- この URL のパソコンデータ
- Origin 全体のモバイルデータ
- Origin 全体のデスクトップデータ
このセクションの右上と右上のコントロールで切り替えることができます。URL レベルで表示するのに十分なデータが URL にはないものの、元のデータがある場合は、PageSpeed Insights には常に元のデータが表示されます。
オリジン全体の LCP が個々のページの LCP とは大きく異なる場合があります。これは、そのページでの LCP の読み込み方法とそのオリジンの他のページの LCP の読み込み方法によって異なります。また、ユーザーがこれらのページにどのように移動したかによっても影響を受けます。ホームページは新規ユーザーがアクセスする傾向があるため、キャッシュに保存されたコンテンツがなく「コールド」状態で読み込まれることがあり、多くの場合、ウェブサイトの中で最も遅いページになります。
CrUX データの 4 つのカテゴリを見ると、LCP の問題がこのページに固有のものなのか、それともより一般的なサイト全体の問題なのかを理解するのに役立ちます。同様に、LCP に問題があるデバイスタイプを確認できます。
PageSpeed Insights の CrUX 補足指標を使用する
LCP の最適化を検討している場合は、First Contentful Paint(FCP)と Time to First Byte(TTFB)のタイミングも使用する必要があります。これらは、LCP に関する貴重な分析情報を得ることができる優れた診断指標です。
TTFB は、ユーザーがページへ移動し(たとえばリンクをクリックするなど)、HTML ドキュメントの最初のバイトを受信するまでの時間です。TTFB が高いと、2.5 秒の LCP を達成することが困難、または不可能な場合があります。
TTFB が高い原因としては、複数のサーバー リダイレクトがある、ユーザーが最寄りのサイト サーバーから遠く離れている、ユーザーがネットワークの状況が良くない、クエリ パラメータが原因でキャッシュ コンテンツを利用できないことなどが考えられます。
ページのレンダリングが始まると、最初のペイント(背景色など)が行われ、その後にコンテンツ(サイトのヘッダーなど)が表示されます。初期コンテンツの外観は FCP によって測定されます。FCP と他の指標との差分は非常に明確です。
TTFB と FCP の差が大きい場合は、ブラウザでレンダリングをブロックするアセットを大量にダウンロードする必要があることを示している可能性があります。また、意味のあるコンテンツをレンダリングするために多くの作業を行わなければならないことを示すこともあります。これは、クライアントサイドのレンダリングに大きく依存するサイトの典型的なサインです。
FCP と LCP の差分が大きい場合は、LCP リソースはブラウザですぐに優先して利用できないか(たとえば、最初の HTML では使用できない JavaScript によって管理されているテキストや画像)、または LCP コンテンツを表示する前にブラウザで他の作業が完了していないことを示します。
PageSpeed Insights の Lighthouse のデータを使用する
PageSpeed Insights の Lighthouse セクションでは、LCP を改善するためのガイダンスがいくつか提示されていますが、まず、提供されている LCP が CrUX が提供する実際のユーザーデータとおおむね一致しているかどうかを確認する必要があります。Lighthouse と CrUX の相違がある場合は、CrUX のほうがユーザー エクスペリエンスをより正確に把握できる可能性が高くなります。CrUX データが元のページに関するものではなく、ページ全体のデータであることを確認してください。
Lighthouse と CrUX の両方で改善が必要な LCP 値が示された場合、Lighthouse のセクションで、LCP を改善する方法について有益なガイダンスを得ることができます。次のように、[LCP] フィルタを使用して、LCP に関連する監査のみを表示できます。
改善のための [最適化] のほかに、[診断] では、問題の診断に役立つ詳細情報を確認できます。Largest Contentful Paint 要素の診断では、LCP を構成するさまざまなタイミングの有用な内訳が表示されます。
次は、これらのサブパートについて詳しく説明します。
LCP の内訳
PageSpeed Insights でこの指標を改善する方法が得られない場合、LCP の最適化はより複雑な作業になることがあります。タスクが複雑な場合は一般的に、より小さく管理しやすいタスクに分割し、それぞれを個別に対処することをおすすめします。
このセクションでは、LCP を最も重要なサブパートに分ける方法論を示し、各パートを最適化するための具体的な推奨事項とベスト プラクティスを紹介します。
通常、ほとんどのページの読み込みには複数のネットワーク リクエストが含まれますが、LCP を改善する機会を特定するには、まず次の 2 つに着目する必要があります。
- 最初の HTML ドキュメント
- LCP リソース(該当する場合)
ページ上の他のリクエストが LCP に影響を与える可能性がありますが、これら 2 つのリクエスト、特に LCP リソースの開始時間と終了時間により、ページが LCP 向けに最適化されているかどうかがわかります。
LCP リソースを特定するには、デベロッパー ツール(前述の PageSpeed Insights、Chrome DevTools、WebPageTest など)を使用して LCP 要素を特定します。そこから、ページによって読み込まれるすべてのリソースのネットワーク ウォーターフォールで、要素によって読み込まれた URL を(再び、該当する場合は)照合できます。
たとえば、以下の可視化では、これらのリソースが一般的なページ読み込みのネットワーク ウォーターフォール図でハイライト表示されています。この図では、LCP 要素のレンダリングには画像リクエストが必要です。
十分に最適化されたページの場合、LCP リソース リクエストの読み込みをできるだけ早く開始し、LCP リソースの読み込みが完了した後に可能な限り早く LCP 要素を表示する必要があります。特定のページがこの原則に従っているかどうかを可視化するには、合計 LCP 時間を次のサブパートに分割します。
- 最初のバイトまでの時間(TTFB)
- ユーザーがページの読み込みを開始してから、ブラウザが HTML ドキュメント レスポンスの最初のバイトを受け取るまでの時間。
- リソース読み込みの遅延
- TTFB から、ブラウザが LCP リソースの読み込みを開始するまでの時間。LCP 要素のレンダリングにリソースの読み込みを必要としない場合(たとえば、要素がシステム フォントでレンダリングされるテキストノードの場合)、この時間は 0 です。
- リソースの読み込み期間
- LCP リソース自体の読み込みにかかる時間。LCP 要素がレンダリングにリソースの読み込みを必要としない場合、この時間は 0 です。
- 要素のレンダリング遅延
- LCP リソースの読み込みが完了してから、LCP 要素が完全にレンダリングされるまでの時間。
各ページの LCP は、この 4 つのサブカテゴリで構成されます。この 2 つの間にギャップや重複はなく、合計で完全な LCP 時間になります。
各ページの LCP 値は、これら 4 つのサブパートに分けられます。それらの間に重複やギャップはありません。合計が完全な LCP 時間になります。
LCP を最適化する場合は、これらのサブ要素を個別に最適化することをおすすめします。ただし、それらすべてを最適化する必要があることにも留意する必要があります。場合によっては、ある部分に最適化を適用しても LCP は改善されず、節約された時間が別の部分にシフトするだけです。
たとえば、以前のネットワークのウォーターフォールでは、画像の圧縮率を高めるか、より最適な形式(AVIF や WebP など)に切り替えてファイルサイズを縮小すると、リソースの読み込み時間は短縮されますが、要素レンダリングの遅延のサブパートに時間が移るため、実際には LCP は改善されません。
その理由は、このページでは、JavaScript コードの読み込みが完了するまで LCP 要素が非表示になり、その後すべてを一度に表示されるためです。
この例は、最適な LCP を達成するために、これらすべてのサブ要素を最適化する必要がある点を示しています。
最適なサブパート時間
LCP の各サブパートを最適化するには、適切に最適化されたページで、これらのサブパートの理想的な内訳がどのようなものかを理解することが重要です。
4 つの部分のうち、2 つは名前に「delay」という単語が含まれています。これが、これらの時間をできるだけ 0 に近づけたいという手がかりになります。他の 2 つの部分はネットワーク リクエストに関わるもので、その性質上、時間がかかります。
これらの時間の内訳はガイドラインであり、厳格なルールではありません。ページの LCP 時間が一貫して 2.5 秒以内であれば、相対的な比率は関係ありません。しかし、いずれかの「遅延」部分に不要な時間を大量に費やしている場合、2.5 秒の目標を常に達成することは非常に困難になります。
LCP 時間の内訳は、以下のように考えることができます。
- LCP の時間のほとんどは、HTML ドキュメントと LCP ソースの読み込みに費やされます。
- LCP の前にこれら 2 つのリソースのいずれかが読み込まれていない場合は、改善の余地があります。
各要素を最適化する方法
適切に最適化されたページで各 LCP のサブパートの時間がどのように変化するかがわかったところで、次はページの最適化に取り掛かります。
以降の 4 つのセクションでは、各要素を最適化するための推奨事項とベスト プラクティスを紹介します。これらは、最も効果が高いと思われる最適化から順に表示されます。
1. リソース読み込みの遅延を排除する
このステップの目標は、LCP リソースの読み込みをできるだけ早く開始できるようにすることです。理論上は、TTFB の直後にリソースの読み込みを開始するのは最も早いものの、実際にはブラウザが実際にリソースの読み込みを開始するまでに常にある程度の遅れが生じます。
目安として、LCP リソースの読み込みは、そのページで最初に読み込まれたリソースと同時に開始する必要があります。言い換えると、LCP リソースの読み込みが最初のリソースよりも遅れて開始される場合、改善の余地があります。
一般的に、LCP リソースの読み込み速度に影響を与える要因は次の 2 つです。
- リソースが検出されたとき。
- リソースに付与される優先度。
リソースの検出時に最適化する
LCP リソースの読み込みをできるだけ早く開始するには、ブラウザのプリロード スキャナが最初の HTML ドキュメント レスポンスでリソースを検出できることが重要です。たとえば、次の場合、ブラウザは HTML ドキュメントのレスポンスをスキャンして LCP リソースを検出できます。
- LCP 要素は
<img>
要素であり、そのsrc
属性またはsrcset
属性が最初の HTML マークアップに含まれています。 - LCP 要素には CSS の背景画像が必要ですが、その画像は HTML マークアップの
<link rel="preload">
を使用して(またはLink
ヘッダーを使用して)プリロードされます。 - LCP 要素は、レンダリングにウェブフォントが必要なテキストノードです。フォントは、HTML マークアップの
<link rel="preload">
を使用して(またはLink
ヘッダーを使用して)読み込まれます。
HTML ドキュメントのレスポンスをスキャンしても LCP リソースを検出できない場合の例をいくつか示します。
- LCP 要素は、JavaScript を使用してページに動的に追加される
<img>
です。 - LCP 要素は、
src
属性またはsrcset
属性(多くの場合data-src
またはdata-srcset
)を非表示にする JavaScript ライブラリとともに遅延読み込みされます。 - LCP 要素には CSS 背景画像が必要です。
いずれの場合も、ブラウザはスクリプトを実行するか、スタイルシートを適用する必要があります(通常、ネットワーク リクエストが完了するまで待機します)。これにより、LCP リソースを検出して読み込みを開始できるようになります。これは最適ではありません。
リソースの読み込みを不必要に遅延なくするために、LCP リソースを HTML ソースから検出できるようにする必要があります。リソースが外部の CSS または JavaScript ファイルからのみ参照される場合、LCP リソースは高い取得優先度でプリロードする必要があります。次に例を示します。
<!-- Load the stylesheet that will reference the LCP image. -->
<link rel="stylesheet" href="/path/to/styles.css">
<!-- Preload the LCP image with a high fetchpriority so it starts loading with the stylesheet. -->
<link rel="preload" fetchpriority="high" as="image" href="/path/to/hero-image.webp" type="image/webp">
リソースに与えられる優先度を最適化する
LCP リソースが HTML マークアップから検出可能であっても、最初のリソースから読み込みが開始されない場合があります。これは、ブラウザ プリロード スキャナの優先ヒューリスティックが、そのリソースが重要であると認識していない場合、または他のリソースの方が重要であると判断した場合に発生することがあります。
たとえば、<img>
要素で loading="lazy"
を設定すると、HTML を使用して LCP 画像を遅らせることができます。遅延読み込みを使用すると、レイアウトで画像がビューポートにあることを確認するまでリソースは読み込まれないため、読み込みが遅くなる可能性があります。
遅延読み込みを行わない場合でも、画像はレンダリングをブロックするリソースではないため、ブラウザによって最初に高い優先度で読み込まれることはありません。fetchpriority
属性を使用して、優先度の高いリソースについてブラウザにヒントを与えることができます。
<img fetchpriority="high" src="/path/to/hero-image.webp">
ページの LCP 要素である可能性が高い場合は、<img>
要素に fetchpriority="high"
を設定することをおすすめします。ただし、1 枚または 2 枚以上の画像に高い優先度を設定すると、LCP を減らすうえで優先度の設定が役に立たなくなります。
また、ドキュメントのレスポンスの初期段階にあるものの、スタイル設定により表示されない画像(起動時に表示されないカルーセル スライドの画像など)の優先度を下げることもできます。
<img fetchpriority="low" src="/path/to/carousel-slide-3.webp">
特定のリソースの優先度を下げると、そのリソースを必要とするリソースにより多くの帯域幅を割ける可能性はありますが、注意が必要です。常に DevTools でリソースの優先度を確認し、ラボやフィールドのツールで変更をテストする。
LCP リソースの優先度と検出時間を最適化すると、ネットワークのウォーターフォールは次のようになります(LCP リソースは最初のリソースと同時に開始されます)。
2. 要素のレンダリング遅延を排除する
このステップの目標は、リソースの読み込みが終了した後、どのようなタイミングであっても、LCP 要素がすぐにレンダリングできるようにすることです。
リソースの読み込み完了直後に LCP 要素がレンダリングできない主な理由は、次のような理由でレンダリングがブロックされていることです。
<head>
のスタイルシートまたは同期スクリプトがまだ読み込み中であるため、ページ全体のレンダリングがブロックされています。- LCP リソースの読み込みは完了しましたが、LCP 要素はまだ DOM に追加されていません(JavaScript コードの読み込みを待機しています)。
- この要素は、ユーザーを対象とするべきテストを決定中の A/B テスト ライブラリなど、他のコードによって非表示になっています。
- 長いタスクが原因でメインスレッドがブロックされ、レンダリング処理は長いタスクが完了するまで待機する必要があります。
以降のセクションでは、不要な要素のレンダリング遅延の最も一般的な原因に対処する方法について説明します。
レンダリングをブロックするスタイルシートを削減またはインライン化する
HTML マークアップから読み込まれたスタイル シートは、それに続くすべてのコンテンツのレンダリングをブロックします。通常は、スタイルのない HTML をレンダリングしたくないため、問題はありません。ただし、スタイルシートが大きすぎて、LCP リソースよりも読み込みに時間がかかる場合は、次の例のように、リソースの読み込みが完了した後でも LCP 要素がレンダリングされなくなります。
この問題を解決するには、次のいずれかを行います。
- スタイルシートを HTML にインライン化して、追加のネットワーク リクエストを回避する。
- スタイルシートのサイズを縮小します。
一般に、スタイルシートのインライン化は、スタイルシートが小さい場合にのみ推奨されます。HTML 内のインライン コンテンツは、後続のページの読み込み時にキャッシュからメリットを得ることができないためです。スタイルシートが大きすぎて読み込みに LCP リソースよりも時間がかかる場合、そのシートがインライン化に適している可能性は低くなります。
ほとんどの場合、スタイルシートによって LCP 要素のレンダリングがブロックされないようにする最善の方法は、LCP リソースよりも小さくなるようにサイズを小さくすることです。これにより、ほとんどのアクセスでボトルネックを回避できます。
スタイルシートのサイズを小さくするための推奨事項は次のとおりです。
- 未使用の CSS を削除する: Chrome DevTools を使用して、使用されておらず、削除(または保留)できる可能性のある CSS ルールを見つけます。
- 重要性の低い CSS を先送りする: スタイルシートを、最初のページ読み込みに必要なスタイルと、遅延読み込みが可能なスタイルに分割します。
- CSS を最小化、圧縮する: 重要なスタイルについては、転送サイズをできるだけ小さくします。
レンダリングをブロックする JavaScript を遅延またはインライン化する
同期スクリプト(async
属性や defer
属性のないスクリプト)をページの <head>
に追加する必要はほとんどありません。追加すると、ほとんどの場合パフォーマンスに悪影響が及びます。
ページ読み込みのできるだけ早い段階で JavaScript コードを実行する必要がある場合は、別のネットワーク リクエストを待機してレンダリングが遅延しないように、コードをインライン化することをおすすめします。ただし、スタイルシートと同様に、スクリプトをインライン化するのは、スクリプトが非常に小さい場合のみにしてください。
<head> <script src="/path/to/main.js"></script> </head>
<head> <script> // Inline script contents directly in the HTML. // IMPORTANT: only do this for very small scripts. </script> </head>
サーバーサイド レンダリングを使用する
サーバー側レンダリング(SSR)は、クライアント側のアプリケーション ロジックをサーバー上で実行し、HTML ドキュメントのリクエストに対して完全な HTML マークアップで応答するプロセスです。
LCP を最適化するという観点では、SSR には次の 2 つの主な利点があります。
- これで画像リソースは HTML ソースから検出できるようになります(前のステップ 1 を参照)。
- ページのコンテンツを表示する前に、追加の JavaScript リクエストを完了する必要はありません。
SSR の主なデメリットは、サーバー処理に時間がかかるため、TTFB が遅くなる可能性があることです。サーバーの処理時間は制御できる一方で、ユーザーのネットワークやデバイスの機能は制御できないため、このトレードオフは通常それだけの価値があります。
SSR に似たオプションが、静的サイト生成(SSG)または事前レンダリングと呼ばれます。これは、オンデマンドではなく、ビルドステップで HTML ページを生成するプロセスです。アーキテクチャで事前レンダリングが可能な場合、通常はその方がパフォーマンスの点で優れています。
長いタスクを分割する
前述のアドバイスに従っていても、JavaScript コードがレンダリングをブロックせず、要素のレンダリングを行うものでもありません。それでも、LCP が遅延する可能性があります。
最も多い原因は、ページで大きな JavaScript ファイルが読み込まれた場合です。JavaScript ファイルは、ブラウザのメインスレッドで解析して実行する必要があります。つまり、画像リソースが完全にダウンロードされた場合でも、無関係なスクリプトの実行が完了するまでレンダリングを待たなければならない場合があります。
現在、すべてのブラウザはメインスレッドで画像をレンダリングするため、メインスレッドをブロックすると、不要な要素のレンダリング遅延が発生することもあります。
3. リソースの読み込み時間を短縮する
このステップの目標は、リソースのバイトをネットワーク経由でユーザーのデバイスに転送する時間を削減することです。一般的には、次の 3 つの方法があります。
- リソースのサイズを小さくします。
- リソースの移動距離を短くします。
- ネットワーク帯域幅の競合を軽減する。
- ネットワーク時間を完全に排除する
リソースのサイズを縮小する
ページの LCP リソース(存在する場合)は、画像またはウェブフォントのいずれかです。次のガイドで、両方のサイズを削減する方法について詳しく説明します。
リソースの移動距離を短縮する
リソースのサイズを削減するだけでなく、サーバーを地理的に可能な限りユーザーの近くに配置することで、読み込み時間を短縮することもできます。最適な方法は、コンテンツ配信ネットワーク(CDN)を使用することです。
特に画像 CDN は、リソースの移動距離を短縮するだけでなく、一般的にリソースのサイズを縮小するので、サイズ削減の推奨事項がすべて自動的に実装されるため、特に便利です。
ネットワーク帯域幅の競合を減らす
リソースのサイズと移動距離を小さくしても、他の多くのリソースを同時に読み込むと、リソースの読み込みに時間がかかることがあります。この問題はネットワーク競合と呼ばれています。
LCP リソースの fetchpriority
を高く設定し、できるだけ早く読み込みを開始した場合、ブラウザは優先度の低いリソースと競合しないように最善を尽くします。ただし、fetchpriority
の値が大きい多数のリソースを読み込む場合や、一般的に多数のリソースを読み込む場合は、LCP リソースの読み込み速度に影響する可能性があります。
ネットワーク時間を完全になくす
リソースの読み込み時間を短縮する最善の方法は、プロセスからネットワークを完全に除外することです。効率的なキャッシュ制御ポリシーを使用してリソースを提供する場合、そのリソースを再度リクエストしたユーザーはキャッシュから提供されるため、リソースの読み込み時間は実質的にゼロになります。
LCP リソースがウェブフォントの場合は、ウェブフォントのサイズを小さくすることに加え、ウェブフォント リソースの読み込み時にレンダリングをブロックする必要があるかどうかも検討する必要があります。font-display
の値を auto
または block
以外に設定すると、テキストは読み込み中に常に表示されます。追加のネットワーク リクエストに対して LCP がブロックされることはありません。
最後に、LCP リソースが小さい場合は、リソースをデータ URL としてインライン化すると合理的です。これにより、追加のネットワーク リクエストも不要になります。ただし、データ URL を使用する場合は注意点があります。なぜなら、リソースをキャッシュに保存できず、場合によっては追加のデコード コストのためにレンダリングの遅延が長くなる可能性があるためです。
4. 最初のバイトまでの時間を短縮
このステップの目標は、最初の HTML をできるだけ早く配信することです。このステップはデベロッパーが最も制御できないことが多いため、最後に示しています。ただし、後続のすべてのステップに直接影響するため、最も重要なステップでもあります。バックエンドが最初のバイトのコンテンツを配信するまで、フロントエンドでは何も起こりません。したがって、TTFB を高速化するためにできることは、他のすべての負荷指標も改善します。
高速のサイトで TTFB が遅延する一般的な原因は、広告や短縮リンクなど、複数のリダイレクト経由でユーザーがアクセスしていることです。ユーザーがリダイレクトを待たせる回数は最小限に抑えてください。
もう 1 つのよくある原因は、キャッシュに保存されたコンテンツを CDN エッジサーバーから使用できず、すべてのリクエストを配信元サーバーに転送しなければならないことです。これは、訪問者が一意の URL パラメータを分析のために使用している場合に発生することがあります。これには、生成されるページは異なるというわけでもありません。
TTFB の最適化の具体的なガイダンスについては、TTFB の最適化ガイドをご覧ください。
JavaScript で LCP の内訳をモニタリングする
前述の LCP の各サブパートのタイミング情報は、次のパフォーマンス API を組み合わせて JavaScript で取得できます。
このようなタイミングの値を JavaScript で計算するメリットは、データを分析プロバイダに送信したり、デベロッパー ツールに記録してデバッグや最適化に役立てたりできることです。
たとえば、次のスクリーンショットでは、User Timing API の performance.measure()
メソッドを使用して、Chrome DevTools の [Performance] パネルの [Timings] トラックにバーを追加しています。
[Timings] トラックのビジュアリゼーションは、ネットワーク トラックとメインスレッド トラックと並べて表示すると特に便利です。これらのトラックで、対象期間にページ上で他にどのような処理が行われているかを一目で確認できます。
タイミング トラックで LCP のサブパートを可視化するだけでなく、JavaScript を使用して、合計 LCP 時間に対する各サブパートの割合を計算することもできます。この情報を基に、ページが前述の推奨される割合(%)を満たしているかどうかを判断できます。
このスクリーンショットは、各 LCP サブパートの合計時間と、合計 LCP 時間の割合をコンソールに記録する例を示しています。
これらのビジュアリゼーションは、どちらも次のコードを使用して作成されました。
const LCP_SUB_PARTS = [
'Time to first byte',
'Resource load delay',
'Resource load duration',
'Element render delay',
];
new PerformanceObserver((list) => {
const lcpEntry = list.getEntries().at(-1);
const navEntry = performance.getEntriesByType('navigation')[0];
const lcpResEntry = performance
.getEntriesByType('resource')
.filter((e) => e.name === lcpEntry.url)[0];
// Ignore LCP entries that aren't images to reduce DevTools noise.
// Comment this line out if you want to include text entries.
if (!lcpEntry.url) return;
// Compute the start and end times of each LCP sub-part.
// WARNING! If your LCP resource is loaded cross-origin, make sure to add
// the `Timing-Allow-Origin` (TAO) header to get the most accurate results.
const ttfb = navEntry.responseStart;
const lcpRequestStart = Math.max(
ttfb,
// Prefer `requestStart` (if TOA is set), otherwise use `startTime`.
lcpResEntry ? lcpResEntry.requestStart || lcpResEntry.startTime : 0
);
const lcpResponseEnd = Math.max(
lcpRequestStart,
lcpResEntry ? lcpResEntry.responseEnd : 0
);
const lcpRenderTime = Math.max(
lcpResponseEnd,
// Use LCP startTime (the final LCP time) because there are sometimes
// slight differences between loadTime/renderTime and startTime
// due to rounding precision.
lcpEntry ? lcpEntry.startTime : 0
);
// Clear previous measures before making new ones.
// Note: due to a bug, this doesn't work in Chrome DevTools.
LCP_SUB_PARTS.forEach((part) => performance.clearMeasures(part));
// Create measures for each LCP sub-part for easier
// visualization in the Chrome DevTools Performance panel.
const lcpSubPartMeasures = [
performance.measure(LCP_SUB_PARTS[0], {
start: 0,
end: ttfb,
}),
performance.measure(LCP_SUB_PARTS[1], {
start: ttfb,
end: lcpRequestStart,
}),
performance.measure(LCP_SUB_PARTS[2], {
start: lcpRequestStart,
end: lcpResponseEnd,
}),
performance.measure(LCP_SUB_PARTS[3], {
start: lcpResponseEnd,
end: lcpRenderTime,
}),
];
// Log helpful debug information to the console.
console.log('LCP value: ', lcpRenderTime);
console.log('LCP element: ', lcpEntry.element, lcpEntry.url);
console.table(
lcpSubPartMeasures.map((measure) => ({
'LCP sub-part': measure.name,
'Time (ms)': measure.duration,
'% of LCP': `${
Math.round((1000 * measure.duration) / lcpRenderTime) / 10
}%`,
}))
);
}).observe({type: 'largest-contentful-paint', buffered: true});
ローカル デバッグでは、このコードをそのまま使用することも、このデータを分析プロバイダに送信するように変更することもできます。そうすれば、実際のユーザーのページでの LCP の内訳をより詳しく把握できます。
Web Vitals 拡張機能を使用して LCP の内訳をモニタリングする
Web Vitals 拡張機能は、LCP 時間、LCP 要素、これら 4 つのサブ項目をコンソールに記録し、この内訳を簡単に確認できるようにします。
まとめ
LCP は複雑で、そのタイミングはさまざまな要因の影響を受ける可能性があります。しかし、LCP の最適化が主に LCP リソースの負荷を最適化することだと考えれば、物事を大幅に簡素化できる可能性があります。
LCP の最適化は、大まかに次の 4 つのステップにまとめます。
- LCP リソースの読み込みができるだけ早く開始されるようにします。
- リソースの読み込みが完了したらすぐに LCP 要素がレンダリングできるようにします。
- 品質を犠牲にすることなく、LCP リソースの読み込み時間を可能な限り短縮します。
- 最初の HTML ドキュメントをできるだけ早く提出します。
ページでこれらの手順を行うことができれば、ユーザーに最適な読み込みエクスペリエンスを提供できていると確信でき、実際の LCP スコアに反映されているはずです。