Largest Contentful Paint (LCP)とは：測定と最適化の方法

Largest Contentful Paint (LCP)とは何ですか？

Largest Contentful Paintは、画面の表示部分に描画された（画像、動画、またはテキストタイプの）最大のコンテンツ要素のレンダリング時間の測定値です。LCPのタイミングは、ページをリクエストしてから、その最大のコンテンツ要素がウェブページの表示部分（アバブザフォールド）に表示されるまでの時間をミリ秒単位で示します。

Largest Contentful Paintの歴史

考えてみると、LCPはCore Web Vitalsの読み込み（loading）部分を表すには些細な指標に思えるかもしれません。なぜ「ページが読み込まれるまでの時間」として読み込み速度を測定しないのでしょうか？

それは、最新のウェブサイトのほとんどにおいて、ページがいつ読み込まれたかを定義することが困難（あるいは不可能）だからです。遅延読み込み（lazy loading）やプログレッシブロードなどの技術を使用するウェブサイトが増えており、ページは基本的に永遠に読み込みを続ける可能性があります。つまり、ページ速度を単一の時点として測定することはできないのです。

ページの読み込み中には、ユーザーがページを速い、または遅いと感じる原因となる瞬間がいくつかあります。例えば、サーバーの遅延（Time to First Byte）、コンテンツが初めて表示される時（First Contentful Paint）、表示されているビューポートが完成したように見える時（Largest Contentful Paint）、そしてページがインタラクティブになる時（リンクのクリックが可能になる時）など、読み込みプロセスのあらゆるポイントで、サイトが遅く感じられたり速く感じられたりする可能性があります！

Largest Contentful Paint (LCP)が選ばれた理由は、訪問者のユーザーエクスペリエンス（UX）に焦点を当てているからです。LCPが発生した時、訪問者は（裏側でプロセスがまだ実行されていたとしても）ページの読み込みが完了したと考えると推測できます。LCPは、「ページのコンテンツはいつ表示されるのか？」という疑問に答えるために作成されました。これが、LCPがユーザー中心のパフォーマンスの主要な指標として認識されている理由です。

LCP vs FCP：その違いは何ですか？

Largest Contentful Paint (LCP)とFirst Contentful Paint (FCP)はどちらも読み込みパフォーマンスを測定しますが、ページ読み込みのタイムラインにおいて根本的に異なる瞬間を捉えます。FCPは、ブラウザがコンテンツの最初のピクセルを描画した瞬間にトリガーされます。これは、小さなナビゲーションバーや読み込みスピナーである可能性があります。LCPは、意味のある最大の要素がビューポート内にレンダリングされたときにトリガーされます。

このように考えてみてください。FCPはページの読み込みが始まったことを伝え、LCPはページが読み込まれたと感じることを伝えます。Googleは、ユーザーが「速度」として認識するものをより正確に反映しているため、LCPをCore Web Vitalsとして選択しました。

ほとんどのウェブサイトにとって、LCPの最適化を優先すべきです。FCPは読み込みタイムラインの早い段階で発生するため、LCPが速ければ、FCPもほぼ常に速くなります。逆は真ではなく、FCPが速くてもLCPが速いとは限りません。

LCPがビジネスにとって重要である理由

Largest Contentful Paintは、3つのCore Web Vitalsのうちの1つです。Core Web VitalsであるLargest Contentful PaintはSEOにとって重要ですが、それ以上に重要なのは、LCPがUXにとって極めて重要であるということです。訪問者は待たされることを嫌い、モバイルトラフィック（デスクトップトラフィックよりも遅くなる傾向があります）が増加しているため、Largest Contentful Paintの最適化は非常に理にかなっています。

• SEOのため：そうです、Googleは検索結果で最適なページを提供することに重点を置いています。LCPは GoogleのCore Web Vitalsの一部です。Googleは、サイト速度が検索結果の要因であることを明確に述べています。
• 訪問者のため：Google自身の最近の調査によると、読み込み時間が3秒になると、ユーザーがサイトを離れる確率は2倍になります。おそらくご自身でもお気づきでしょう。インターネットをサーフィンしているとき、読み込みの遅いウェブサイトほど煩わしいものはほとんどありません。読み込みの遅いページからすぐに離れてしまう可能性が高いでしょう。
• その他の理由：ページ速度はGoogle 広告スコアの要因です。つまり、広告をより安く購入できます。さらに、Core Web Vitalsに合格することは、Googleのトップストーリーボックスの前提条件の1つです。

高速なLCPは、ページが素早く読み込まれるという印象を訪問者に与えます。その結果、訪問者がページから離脱する可能性が低くなります。

ケーススタディ：Vodafone（LCPを31%改善し、売上が8%増加）

Vodafone Italyは、LCPスコアを最適化する対照実験を実施しました。LCPを31%削減することで、売上が8%増加したことを測定しました。これは相関関係ではなく、体感の読み込みが速くなるほど収益が増加することを証明する直接的なA/Bテストです。この最適化は、LCP画像のプリロードと、レンダリングをブロックするリソースの削減に焦点を当てていました。web.devでVodafoneのケーススタディの全文を読む。

ケーススタディ：Googleフライト（fetchpriorityで700ミリ秒を短縮）

Googleフライトのチームは、ヒーロー画像にfetchpriority="high"を追加し、LCPが700ミリ秒改善されたことを確認しました。このたった1つのHTML属性の変更は、彼らのパフォーマンススプリントにおいて最も影響力のある最適化でした。fetchpriority属性は、他のリソースよりもLCP画像のダウンロードを優先するようブラウザに指示します。Googleフライトの実験が示すように、その影響は劇的なものになり得ます。Core Web Vitalsのリソースの優先順位付けについて詳しく学んでください。

どの要素がLCP要素と見なされますか？

すべての要素がLCP要素と見なされるわけではありません。最大のコンテンツ要素は、ユーザーがページを操作する前に、画面の表示部分（ビューポート）に描画されている必要があります。

要素は次のいずれかである必要があります：

• <img>要素。
• <svg>要素の内部にネストされた<image>要素。
• <video>要素（ポスター画像または最初の動画フレームのいずれか早い方が使用されます）。
• CSSのurl()関数を介して読み込まれた背景画像を持つ要素。（注：これはブラウザのプリロードスキャナーが画像を発見できなくなるため、LCP最適化のアンチパターンです。背景画像の遅延読み込みに関するガイドをお読みください）。

• テキストノードまたはその他のインラインテキスト要素を含むブロックレベル要素（<span>のようなインラインテキスト要素の場合、最も近いブロックレベル要素である<div>または<p>が考慮されます）。

現在、opacity: 0で非表示になっている要素、ビューポートサイズの100%に一致する画像（カバー画像）、およびプレースホルダー（エントロピーの低い画像）など、特定の要素はLCP候補から除外されています。これは仕様の進化に伴い変更される可能性があることに注意してください！

技術的な詳細：LCP要素のサイズの測定

LCPは、ビューポート内で表示されている最大のコンテンツ要素を特定し、一連の正確なルールに基づいてそのサイズを計算します。これらのルールにより、複雑なレイアウトでも一貫性と正確性が保証されます。

• ビューポートのみ：ページの表示部分のみが考慮されます。要素が部分的にしか表示ビューポート内にない場合、考慮されるサイズは切り取られます。
• ボーダー、パディング、マージンなし：すべての要素において、テキストと画像のボーダー、パディング、マージンは完全に無視されます。
• テキストサイズ：テキスト要素は、テキストノードの周りに描画できる最小の長方形として報告されます。
• 画像サイズ：画像の場合、固有の寸法（元の幅と高さ）と表示サイズ（画面上のサイズ）のうち、小さい方がLCP要素サイズの計算に使用されます。
• 最初のサイズがカウントされる：レイアウトが変更されたり、要素のサイズが変更されたりした場合でも、最初のサイズのみがLCPとして考慮されます。
• 削除された要素も含まれる：要素がDOMから削除された場合でも、LCPの候補として残ります。

LCPの動的な性質

Largest Contentful Paint (LCP)は動的な指標です。レンダリングは複雑で段階的に行われる可能性があるため、ページの読み込み中にLCP要素が変化するのは正常なことです。ユーザーが最初の操作を行う前に、ブラウザのパフォーマンスオブザーバーは、LCP候補となり得るすべての要素を特定します。ビューポート内に表示され、以前に特定されたLCP要素よりも大きい新しい要素がレンダリングされた場合、それが新しいLCPになります。

LCPのフィールドデータからの重要なポイント：CoreDashでは、毎日数百万のLCPエントリを追跡しています。その結果、モバイルページビューの場合、LCP要素は多くの場合、段落または見出しのいずれかのテキストベースの要素であることがわかりました。平均して（正確には75パーセンタイルにおいて）、LCP要素がテキストノードや通常の画像である場合、Core Web Vitalsに合格します。LCP要素が背景画像、動画、または遅延読み込み（lazy-loaded）画像である場合、Core Web Vitalsは不合格になる傾向があります。

良いLCPスコアとは何ですか？

Largest Contentful PaintのCore Web Vitalsに合格するには、少なくとも75%の訪問者が「良い（good）」LCPスコアである必要があります。0〜2.5秒のLCPスコアは良い（good）LCPスコアと見なされ、2.5〜4秒のLCPスコアは改善が必要（needs improvement）、4秒を超えるLCPスコアは不良（poor）と見なされます。

実際のLCPデータが示すこと

CoreDashは、毎日何百万もの実際のユーザーのLCP測定値を追跡しています。ウェブ全体のLCPパフォーマンスについて、データが明らかにしていることは次のとおりです。

画像LCPとテキストLCPの比較

画像ベースのLCP要素を持つページの75パーセンタイルのLCPは744ミリ秒であり、テキストベースのLCP要素の388ミリ秒と比べてほぼ2倍の遅さです。これは、画像最適化がLCPスコアを改善するために最も影響力のある領域であることを裏付けています。LCP要素が画像である場合、特に積極的に最適化を行う必要があります。

プリロードと遅延読み込み（Lazy Loading）の影響

プリロードされたLCP画像は、75パーセンタイルが364ミリ秒で「良い（good）」スコア100%を達成しています。対照的に、遅延読み込み（lazy-loaded）されたLCP画像は720ミリ秒と最も遅く、ページ読み込みの4.3%が「不良（poor）」と評価されています。プリロードされていない画像も752ミリ秒と、ほとんど同じくらい悪いパフォーマンスです。結論は明らかです。LCP画像をプリロードし、絶対に遅延読み込み（lazy-load）しないでください。

モバイルとデスクトップのLCPの比較

モバイルのLCP（75パーセンタイルで764ミリ秒）は、デスクトップのLCP（380ミリ秒）の2倍の遅さです。この差は、モバイルネットワークの遅さと、モバイルプロセッサの性能の低さが原因です。Googleはモバイルファーストインデックスを使用しているため、モバイルのLCPの最適化を優先すべきです。

グローバルなLCP統計

HTTP Archive Web Almanac 2025によると、世界中のモバイルページの62%が良いLCPスコア（2.5秒未満）を達成しており、2022年の44%から上昇しています。LCPは依然として合格するのが最も難しいCore Web Vitalsであり、CWVスコア全体の主要なボトルネックとなっています。さらに、モバイルLCP要素の73%は画像であり、モバイルサイトの16%は誤ってLCP画像を遅延読み込み（lazy-load）しています。

LCPの測定方法：4つの重要なフェーズ

Googleによると、Largest Contentful Paintは4つのサブパートに分解できます。各フェーズで全く異なる修正が必要になるため、どのフェーズがボトルネックになっているかを理解することは、効率的な最適化に不可欠です。遅いTime to First Byte (TTFB)にはサーバー側の作業が必要であり、遅いリソース読み込み遅延（resource load delay）にはHTMLの変更が必要です。

ページの最終的なLCP時間は、単一の全体的な値ではありません。これは、4つの異なるサブパートの合計です。この内訳を理解することが、LCPの課題を効率的に診断し修正するための鍵となります。

4つのフェーズの内訳は次のとおりです：

• Time to First Byte (TTFB)：これは純粋なサーバーの応答時間です。DNSルックアップからTCP/TLS接続を経て、ブラウザがHTMLドキュメントの最初のバイトを受信するまでのすべての時間をカバーします。遅いTTFBは、LCPを常に悪化させる根本的な問題です。ウェブ全体で、LCPが不良なサイトはTTFBだけで平均2.27秒を費やしており、これは2.5秒のしきい値のほぼ全体に相当します。TTFBの最適化には、サーバー側のキャッシュ、CDN構成、および効率的なバックエンドコードが含まれます。
• リソース読み込み遅延（Resource Load Delay）：これは「発見のギャップ」です。TTFBが完了してから、ブラウザが実際にLCPリソースのダウンロードを開始するまでの時間を測定します。ここでの遅延が長いということは、ブラウザがLCPリソースを遅れて見つけたことを意味します。これは、CSS背景画像を使用している場合（プリロードスキャナーが発見できないため）、またはクライアントサイドレンダリング（JavaScriptが実行された後にのみLCP要素が表示される場合）の典型的な症状です。修正方法は、LCP要素が初期のHTMLに含まれていることを確認することと、ブラウザが早期に発見できない場合はLCP画像をプリロードすることです。
• リソース読み込み時間（Resource Load Duration）：これは、LCPリソースファイル（画像、フォント、または動画）を実際にダウンロードするのにかかる時間です。このフェーズはファイルサイズとネットワーク条件にすべて依存します。最適化とは、AVIFやWebPなどの最新の画像フォーマットを使用し、srcsetを使用してレスポンシブ画像を実装し、適切な圧縮を使用してCDN経由でアセットを提供することを意味します。
• 要素レンダリング遅延（Element Render Delay）：これが最後の遅延です。LCPリソースのダウンロードが完了してから、要素が画面に完全にレンダリングされるまでの時間を測定します。この遅延は、ブラウザのメインスレッドが他のタスク、特にJavaScriptの処理によってブロックされていることが原因でほぼ常に発生します。レンダリングをブロックするCSSと同期スクリプトが最も一般的な原因です。

これらの重点領域のそれぞれを最適化することで、Largest Contentful Paintを改善できます。実行する必要がある手順を理解するには、Largest Contentful Paint (LCP)の問題の修正と特定をお読みください。

よくあるLCPのミス

CoreDashを通じて何百万ものページ読み込みを分析した結果、3つのLCPのミスが他のどのミスよりもはるかに頻繁に現れました。これらを避けることで、ほとんどのサイトが合格のLCPスコアに到達するでしょう。

ミス1：LCP画像を遅延読み込み（Lazy-Load）する

ヒーロー画像にloading="lazy"を追加することは、最も一般的なLCPのミスです。遅延読み込み（lazy loading）は、画像がスクロールして表示されるまで意図的にダウンロードを遅らせるようにブラウザに指示します。（すでにビューポート内にある）LCP画像の場合、これは全く不必要な遅延を引き起こします。CrUXのデータによると、モバイルサイトの16%がこのミスを犯しています。CoreDashのデータによると、遅延読み込み（lazy-loaded）されたLCP画像は75パーセンタイルが720ミリ秒で4.3%が不良（poor）なエクスペリエンスであるのに対し、プリロードされた画像は364ミリ秒で0%が不良です。遅延読み込みされたLCP画像を修正する方法についての完全なガイドをお読みください。

ミス2：LCP画像をプリロードしない

遅延読み込みを行わなくても、多くのサイトはブラウザにLCP画像について十分早く伝えることに失敗しています。画像のURLがCSSの解析後やJavaScriptの実行後にのみ発見された場合、ブラウザはダウンロードを開始する前に何百ミリ秒も無駄にします。修正するには、ドキュメントの<head>にプリロードヒントを追加します：

<link rel="preload" as="image" href="/img/hero.webp" fetchpriority="high">

これにより、ブラウザはCSSやレイアウトの計算を待たずに、すぐに画像のダウンロードを開始するようになります。fetchpriority="high"と組み合わせることで、最大の影響を得ることができます。LCP画像のプリロードに関するガイドで詳細をご覧ください。

ミス3：LCPにCSSの背景画像を使用する

background-image: url(...)を介して読み込まれるCSSの背景画像は、ブラウザのプリロードスキャナーからは見えません。ブラウザは、HTMLをダウンロードし、CSSを解析し、レンダーツリーを構築するまで、それらを発見できません。これにより、リソースの読み込み遅延が大幅に増加します。CrUXのデータによると、モバイルページの9%がLCP要素としてCSS背景画像を使用しています。解決策は、代わりにfetchpriority="high"属性を持つ標準の<img>タグを使用することです：

<img src="/img/hero.webp"
     alt="Descriptive alt text"
     width="1200"
     height="600"
     fetchpriority="high">

fetchpriority="high"属性は、この画像がページ上で最も優先度の高いリソースであることをブラウザに直接伝えるシグナルです。Googleフライトのケーススタディで実証されているように、この1つの属性だけでLCPを700ミリ秒短縮できます。より深く理解するには、リソースの優先順位付けに関するガイドをご覧ください。

Largest Contentful Paintの測定方法

Largest Contentful Paint (LCP)は、純粋なJavaScript、Labデータ、およびFieldツールを使用して測定できます。それぞれに長所と短所があります。

JavaScriptでLargest Contentful Paintを測定する

JavaScriptを使用してLargest Contentful Paint (LCP)を測定するには、Performance Observer APIが迅速な解決策を提供します。次のコードスニペットは、LCPのタイミングと要素情報をキャプチャする方法を示しています：

new PerformanceObserver((list) => {
    const lcpEntry = list.getEntries().at(-1);
    console.log('LCP value: ', lcpEntry.startTime);
    console.log('LCP element: ', lcpEntry.element, lcpEntry.url);
  }).observe({ type: 'largest-contentful-paint', buffered: true });

このスニペットは、LCPエントリが報告されたときにそれを追跡し、コンソールにタイムスタンプと要素の詳細を表示します。より詳細な洞察を得るには、Web Vitals Libraryの使用を検討してください。

Chrome DevToolsでLargest Contentful Paint (LCP)を測定する

1. Ctrl+Shift+I（Macの場合はCmd+Option+I）を押して、Chrome DevToolsを開きます。
2. Performanceタブに移動します。
3. ページを再読み込みして、Core Web Vitalsを表示します。

DevToolsのPerformanceタブには、Largest Contentful Paintのタイミングと要素を含む、Core Web Vitalsに関する情報が表示されるようになりました。

LabツールとFieldツールでLargest Contentful Paintを測定する

明確にしておきましょう。LabデータとFieldデータは2つの異なる目的を果たします。両方が必要です。

• Fieldデータ（RUMおよびCrUX）は、Core Web Vitalsに合格するために実際に重要となる唯一のデータです。これは実際のユーザーが体験するものです。GoogleはCrUXデータセットからこのデータを使用します。問題があるかどうかを調べるには、ここから始めます。
• Labデータ（Lighthouseなど）は、制御されたテストです。Googleがランキングに使用するものではありませんが、デバッグには不可欠です。なぜ問題があるのかを突き止めるためにこれを使用します。

必須ツールの簡単なガイドは次のとおりです：

Largest Contentful Paintの改善

LCPの最適化には、4つのフェーズに対処する体系的なアプローチが必要です。ネットワーク関連であれCPU集約型であれ、LCP要素が描画される前に発生するすべてのことが、LCPスコアに影響を与える可能性があります。1つの修正だけを追い求めるのではなく、チェーン全体を理解してください。 ハイレベルな戦略は次のとおりです：

• TTFBの最適化：サーバーは高速である必要があります。TTFBが遅い場合、他のすべては意味がありません。これには、サーバー側のキャッシュ、CDNの使用、効率的なバックエンドコードが含まれます。詳細については、TTFBの最適化に関するガイドをお読みください。
• リソース読み込み遅延（Resource Load Delay）の排除：LCP要素が初期のHTMLに含まれていることを確認し、ブラウザのプリロードスキャナーが即座にそれを見つけられるようにします。LCPにCSSの背景画像を使用することは避けてください。発見が遅れた重要な画像をプリロードします。リソース読み込み遅延の修正に関するガイドで方法を学んでください。
• リソース読み込み時間（Resource Load Time）の削減：LCPファイルのサイズを小さくします。これは、AVIFのような最新の画像フォーマット、レスポンシブ画像、および適切な圧縮を使用することを意味します。LCP画像を最適化する方法についての完全なガイドをご覧ください。また、実際のプロジェクトでどのようにしてLCPを70%下げたかについても読むことができます。
• 要素レンダリング遅延（Element Render Delay）の短縮：メインスレッドのブロックを停止します。重要でないJavaScriptを遅延させ、長いタスクを分割し、レンダリングをブロックするCSSを最小限に抑えます。これについては、要素レンダリング遅延の修正に関するガイドで説明しています。

関連ガイド

このハブページでは、Largest Contentful Paintについて高いレベルで説明しています。LCP最適化の各側面に関する詳細かつ実践的なガイダンスについては、以下の専用ガイドをご覧ください：

• LCPの問題の修正と特定：Chrome DevTools、WebPageTest、およびCoreDashを使用して、遅いLCPの正確な原因を見つけるためのステップバイステップの診断ガイド。
• LCP画像の最適化：画像フォーマット、レスポンシブ画像、圧縮、およびすべてのデバイスに最適な画像を提供することに関するすべて。
• リソース読み込み遅延（Resource Load Delay）：プリロード、fetchpriority、およびCSSの背景画像の回避を含め、ブラウザが可能な限り早くLCPリソースを発見できるようにする方法。
• リソース読み込み時間（Resource Load Duration）：ファイルサイズの最適化、CDN構成、および最新の圧縮を通じて、LCPリソースの実際のダウンロード時間を短縮します。
• 要素レンダリング遅延（Element Render Delay）：JavaScriptとCSSによるメインスレッドのブロックを減らすことで、リソースのダウンロードから画面のレンダリングまでの遅延を排除します。