Largest Contentful Paint (LCP) とSEO

TL;DR — Largest Contentful Paint (LCP) は、画面上の最大の要素（通常はヒーロー画像や大きなテキストブロック）が、ページにアクセスしてから表示されるまでの時間を測定します。2,5秒未満が良好です。これはGoogleのCore Web Vitalsの1つであり、多くのサイトが苦労する指標です。

LCPとは

サイトの第一印象は、読み込みがどれだけ速く見えるかです。LCPはそれに数値を与えようとします。ビューポート（スクロールせずに見える部分）内で最も大きな可視要素を読み込むのにかかる時間を測定します。

その「最大の要素」は通常、次の2つのいずれかです：

• 大きな画像 — ヒーローバナー、商品写真、注目画像。
• 大きなテキストブロック — 画像で始まらない記事ページでよく見られます。

LCPは、ページの読み込みが開始された時点から、その要素のレンダリングが完了する瞬間までの時間です。数値が低いほど、ページの体感速度が速くなります。

スコア

GoogleはLCPを3つのカテゴリに分類しています：

• 良好: 2,5秒以下
• 改善が必要: 2,5秒から4秒
• 不良: 4秒以上

目標は2,5秒の基準です。そして、これは一度だけ実行するテストではなく、サイトの実際の訪問者に基づいて評価されます。つまり、実際のユーザーが実際のスマートフォンと接続環境で受ける体験です。

なぜ難しいのか

LCPは、人々が最も苦労するCore Web Vitalです。それは、最も多くの可動部分があるためです：サーバーが応答し、ブラウザが画像を見つけてダウンロードし、実際に描画する必要があります。これらのステップのいずれかで遅延が発生すると、全体の数値が悪化します。画像の圧縮は一般的な最初の推測ですが、効果があることもありますが、実際のボトルネックではないことがよくあります。

また、デスクトップよりもモバイルの方が難しいです。スマートフォンは接続が遅く、処理能力も低いためです。

最初にやること

最も一般的な間違いを修正する3つのクイックウィン：

1. メイン画像を遅延読み込みしない。 「遅延読み込み」は、ブラウザに画像の取得を待つように指示します。これはページの下部にあるものには最適ですが、ヒーロー画像に適用すると、画面上で最も重要なものを意図的に遅らせていることになります。 Evidence for this claim An LCP image should not be lazy-loaded, and reducing resource load delay is a primary LCP optimization. Scope: web.dev guidance for image-based LCP elements. Confidence: high · Verified: 2026-07-14 web.dev: Optimize LCP
2. ブラウザにメイン画像が重要であることを伝える — それを正確に行う属性（fetchpriority="high"）があります。実際にLCP候補となる1つの画像に設定してください。複数の画像に設定するとシグナルが薄まります。
3. サーバーを高速化する。 サーバーの応答が遅い場合、他の対策はあまり意味がありません。

完全なメンタルモデル（LCPの4つのサブパート、LCP要素の見つけ方、レンダリングとフォント関連、ランキングへの実際の影響度）が必要ですか？ Advanced タブに切り替えてください。

TL;DR — LCPは、ページの読み込み開始時点に対する、ビューポート内で表示される最大の画像またはテキストブロックのレンダリング時間です。良好は実ユーザーの75パーセンタイル（デバイス別）で**≤ 2,5秒**、2,5〜4秒は改善が必要、4秒超は不良です。これはCore Web Vitalsの1つであり、4つのサブパート（TTFB、リソース読み込み遅延、リソース読み込み時間、要素レンダリング遅延）に分かれます。通常、TTFBと読み込み時間が支配的です（固定の割合ではなくガイドラインです。自分のページを診断してください）。主な修正策：LCP画像を遅延読み込みしない、実際の候補にfetchpriority="high"を追加する、HTMLにない場合はプリロードする、レンダリングをブロックするCSS/JSを排除する、TTFBを修正する。これはフィールド指標であり、ラボツールは近似値しか提供しません。また、LCP要素は読み込み中に変化する可能性があります。GoogleはCore Web Vitalsがランキングシステムに影響することを確認していますが、正確なLCPの重みを公開しておらず、タイブレーカーとも呼んでいません。コンテンツの関連性が依然として支配的です。

LCPが実際に測定するもの

LCPは、ユーザーがページに最初に移動した時点を基準として、ビューポートに表示される最大の画像またはテキストブロックのレンダリング時間を報告します。Google自身の枠組みでは、メインコンテンツがユーザーに表示されるタイミングに最も近い標準化されたプロキシです。これは、First Meaningful PaintやSpeed Indexなどの以前の曖昧な指標に取って代わりました。

最初に人々を混乱させるいくつかの点：

• 「ページの読み込み時間」ではありません。 ページのすべてのリソースが取得されていても、最大の要素のレンダリングがブロックされていれば、LCPは遅くなります。LCPはページ全体ではなく、その1つの要素に関するものです。
• FCPと同じではありません。 First Contentful Paintは何らかのコンテンツが最初に表示されたときに発生します。LCPは最大の要素を待ちます。ページのFCPが速く（ナビゲーションバーが描画される）、LCPが遅い（ヒーロー画像の読み込みが遅い）場合があります。
• 動的な指標です。 ブラウザは、より大きな要素が表示されるたびに新しいLCP候補を発行します。ユーザーが操作（タップ、スクロール、キー押下）するか、ページがアンロードされる前の最後のエントリがカウントされる値です。操作によって表示内容が変わることが多いため、レポートはそこで停止します。後でDOMから削除された候補は、それ自体のエントリを消去しません。レポートが停止する前にさらに大きな要素がレンダリングされない限り、報告された要素のままです。

しきい値 — そしてなぜ2,5秒なのか

デバイスタイプごとにセグメント化された、実際のユーザーのページ読み込みの75パーセンタイルで評価されます。つまり、オリジンが合格するには、4回の訪問のうち3回が2,5秒未満である必要があります。

なぜ具体的に2,5秒なのか？ Googleのしきい値の方法論は、2つのことに依存していました。「即時」と感じられる帯域としておよそ1〜3秒を指す人間の知覚研究と、2,5秒が十分に最適化されたサイトで一貫して達成可能であり、簡単すぎないことを示すCrUXの達成可能性データです。1,5秒や2,0秒のようなより厳しいターゲットは、十分な数のオリジンで一貫して達成できなかったため、採用されませんでした。

LCP要素としてカウントされるもの

LCPで考慮される要素タイプ：

• <img> 要素
• <svg> 内の <image> 要素
• <video> 要素（ポスター画像の読み込み時間、または最初のフレームのうち、どちらか早い方）
• CSSの url() 関数で読み込まれた背景画像を持つ要素
• テキストノードまたは他のインラインテキストの子要素を含むブロックレベル要素

報告されるサイズは、ビューポートで実際に表示されているものです。クリップされたり、スクロールで見えなくなった部分はカウントされず、画像の場合は表示サイズまたは固有サイズのうち小さい方が使用されます。マージン、パディング、ボーダーは無視されます。ヒューリスティックによって除外される要素がいくつかあります：opacity: 0 のもの、ビューポート全体を覆う要素（背景として扱われる）、低エントロピーのプレースホルダー画像などです。

約4分の3のページで、LCP要素は画像です。したがって、画像の最適化が通常は最初の正しい手順です。ただし、常にそうとは限らず、常に圧縮とは限りません（これについては次で詳しく説明します）。残りの部分はテキストLCPであり、そこでのレバーはまったく異なります：それは画像の重さではなく、フォントの読み込みです。

4つのサブパート — ほとんどの記事が省略する部分

これは、私がLCP診断を始める際に使用するフレームワークです。web.devはLCPを4つの連続したサブパートに分割しています：

1. Time to First Byte (TTFB) — ユーザーがページの読み込みを開始してから、ブラウザがHTMLの最初のバイトを受信するまで。典型的な割合：LCP全体の約40%。
2. リソース読み込み遅延 — TTFBからブラウザがLCPリソースの読み込みを開始するまでのギャップ。これは発見時間です。典型的な割合：10%未満。
3. リソース読み込み時間 — LCPリソース自体のダウンロードにかかる時間。典型的な割合：約40%。
4. 要素レンダリング遅延 — リソースの読み込みが完了してから要素が実際に描画されるまで。典型的な割合：10%未満。

この表の背後にある原則: LCP時間の大部分は、HTMLドキュメントとLCPリソースの読み込みに費やされるべきです。どちらも読み込まれていない時間は、改善の機会です。

web.devは、これらのパーセンテージはガイドラインであり、厳格なルールではないと明言しています。絶対的な秒数の目標に変換したり、すべてのページをこの割合に合わせる必要はありません。これらは互いに対してのみ意味を持ち、LCPがすでに一貫して2,5秒以内であれば、相対的な割合はまったく重要ではありません。この表を使用して、あなたのページでどのサブパートが過剰な割合を占めているかを特定し、その部分だけを修正してください。正確な40/10/40/10の割合を追い求めるためではありません。

そして、一般的な前提を覆す点があります。2025年2月現在、これらの4つのサブパートは画像LCPについてCrUX APIで利用可能であり、ChromeチームによるHTTP Archiveデータの分析では、画像のダウンロード時間がLCP時間の最小部分であることが多いことが判明しました。言い換えれば、「画像を圧縮するだけ」では、間違ったサブパートを修正することがよくあります。TTFBと発見遅延が、より大きな改善のレバーとなることが多いのです。

LCP要素を見つける方法

最適化する前に、どの要素がLCPであり、どのサブパートがボトルネックかを特定してください。

• PageSpeed Insights — DiagnosticsセクションでLCP要素が示され、フィールドデータタブで実際のユーザースコアが表示されます。
• Chrome DevTools — Performanceパネルでタイムライン上のLCPノードがマークされます。
• web-vitals JSライブラリ — 独自の実ユーザーモニタリングからLCP（および要素）をログに記録します。

LCPを改善する方法

各修正を、それが対象とするサブパートに対応付けます。

リソース読み込み遅延（発見）を修正します。 これは最も効果が高く、最も一般的に壊れているものです。

• LCP画像を遅延読み込みしないでください。 LCP要素にloading="lazy"を指定すると、常に不要な読み込み遅延が追加されます。遅延読み込みは、スクロールしないと見えない画像用に予約してください。
• 可能性のあるLCP画像に**fetchpriority="high"**を追加して、ブラウザが早期に高い優先度で取得できるようにします。
• 画像が初期HTMLで発見できない場合（CSSやJavaScript経由で読み込まれる場合など）は、<link rel="preload">でプリロードします。JS経由でヒーロー画像を読み込むのは、ブラウザのプリロードスキャナーからURLが隠れるため、まさにアンチパターンです。
• 重要なリソースを同一オリジンでホストし、ブラウザが余分な接続設定を支払わないようにします。

プリロードとfetchpriorityは異なる問題を解決するため、習慣的に両方を使用しないでください。プリロードは、ブラウザのプリロードスキャナーが遅れて発見するリソース（JSやCSSで読み込まれる画像など）を公開します。fetchpriorityは、ブラウザがすでに見つけたリソースの取得優先度を変更します。発見と優先度がすでに正しい場合（画像が初期HTML内のプレーンな<img>である場合）、どちらを追加しても、余分なリクエスト以外にほとんど効果はありません。トレースを確認し、実際の問題に一致する方を適用し、フィールド番号が動いたことを確認してください。

要素レンダリング遅延を修正します。

• レンダリングをブロックするCSSを削減またはインライン化し、重要でないスタイルは遅延させます。
• <head>内の同期スクリプトを避けます。
• サーバーサイドレンダリングまたは静的生成を優先して、マークアップが描画可能な状態で届くようにし、メインスレッドの長いタスクを分割します。

リソース読み込み時間を短縮します。

• 最新の画像形式（WebP、AVIF）、適切な圧縮、CDNを使用します。
• 効率的なCache-Controlを使用します。また、ネットワーク競合を無視しないでください。他のスクロールしないと見えない画像を遅延読み込みすることで、帯域幅を解放し、LCP画像がより早く表示されるようにできます。

TTFBを短縮します。

• リダイレクトを最小限にし、不要な一意のURLパラメータを削除し、サーバーの応答時間を最適化します。LCPには、前のページからのアンロード時間、接続設定、リダイレクト時間が含まれることに注意してください。これらはすべてTTFBに含まれます。

特別なケース: テキストベースのLCP。 最大の要素がテキストの場合、クリティカルパスは画像の重さではなくフォントの読み込みです。font-display: optional またはシステムフォントを使用すると、フォントによるレンダリング遅延がなくなります。font-display: swap をフォントファイルのプリロードなしで使用すると、遅延が発生する可能性があります。

ラボとフィールド — この違いは重要です

LCPは基本的にフィールド指標です。GoogleはCrUXを通じて実際のユーザーで評価し、PageSpeed InsightsのフィールドタブとSearch ConsoleのCore Web Vitalsレポートに表示されます。ランキングに反映されるのはこのフィールドデータです。

ラボツール（Lighthouse、Chrome DevTools、WebPageTest）は、シミュレーション条件下でそれを近似するだけであり、同じスコアリングすら使用していません。Lighthouseはフィールド標準（≤ 2,5秒）よりも厳しいデスクトップしきい値（Good ≤ 1,2秒）を適用します。したがって、Lighthouseのスコアが合格してもCrUXのスコアが合格するとは限らず、その逆も同様です。ラボツールはデバッグと再現に使用し、最終的な判定はフィールドデータを信頼してください。

ラボとフィールドの数値が乖離する理由はもう1つあり、それを知っておくと、異常な読み取り値が原因で幻のバグを追いかけることがなくなります。現在のLargestContentfulPaintブラウザAPI（まだW3Cワーキングドラフト）は、単一のドキュメント読み込みに限定されています。バック/フォワードキャッシュ（bfcache）の復元や同一ドキュメント内のSPAナビゲーションではリセットされず、オフスクリーンで開始されるページ（バックグラウンドタブ、プリレンダリングされたページ）は、タイミングがページが実際に表示されたときではなく読み込みから始まるため、過大な値が報告される可能性があります。また、レポートアルゴリズムは該当するユーザー入力で停止するため、メインコンテンツが表示される前にユーザーが操作した場合、LCPはそれをキャプチャしません。これらはいずれも上記のしきい値テーブルを変更するものではありません。これは、基になるナビゲーションが単純な最初の読み込みではない場合に、特定のセッションの数値が間違って見える理由を説明しています。

LCPはランキングに影響しますか?

はい、GoogleがCore Web Vitalsがランキングシステムにフィードされ、良好なスコアを達成することを推奨しているという意味ではそうです。ただし、現在のSearch Centralドキュメントは正確なLCPの重みを公開しておらず、タイブレーカーとして説明もしていません。Google自身の枠組みは、ページエクスペリエンスが「検索での成功に貢献できる」のは、複数のページがすでに同等で関連性の高いコンテンツを提供しているクエリに対してであり、良好なスコアがランキングの向上を保証するものではないというものです。コンテンツの関連性と品質が依然として支配的です。LCPを最適化するのは、表示が速いページがユーザー（およびコンバージョン）にとって本当に良いからです。メカニズムがランキングのタイブレーカーとして文書化されているからではありません。実際にはそうではないからです。

データからのいくつかの現実: Core Web Vitalsの中で、LCPはサイトが最も改善に苦労する指標であり、モバイルではデスクトップよりも著しく困難です（CPUと接続が遅いため）。3G以下では、2,5秒のしきい値はほぼ達成不可能に感じられることがあります。

位置づけ

LCPは、Interaction to Next PaintおよびCumulative Layout Shiftと並ぶ3つのCore Web Vitalsの1つです。その最初のサブパートであるTime to First Byteは独自の診断指標であり、First Contentful Paintは読み込みタイムライン上でそのすぐ隣にあります。これらはすべてPageSpeed Insights、Lighthouse、Chrome User Experience Report（CrUX）で確認できます。それぞれがこのクラスター内の個別の詳細ガイドです。

AIまとめ

Advancedバージョンの簡潔な見解:

• LCP = 最大の表示画像またはテキストブロックのレンダリング時間。ページの読み込み開始時点からの相対時間です。これは「メインコンテンツがいつ表示されるか」に最も近い標準化された指標です。
• しきい値: 良好 ≤ 2,5 秒、改善が必要 2,5〜4 秒、不良 > 4 秒 — 実ユーザーの75パーセンタイルで、デバイス別に分けられます。これは Core Web Vitals の 3 つのうちの 1 つです。
• ページの読み込み時間でも FCP でもありません。 FCP = 任意のコンテンツの最初のピクセル。LCP = 最大の要素。LCP は動的でもあります — 最大の候補は読み込み中に変わる可能性があり、ユーザー操作の前の最後のものがカウントされます。
• LCP 要素: <img>、<svg> 内の <image>、<video> のポスター、CSS の background-image: url()、またはブロックレベルのテキスト要素。約 4 ページ中 3 ページは画像 LCP で、残りはテキストです（フォントが重要で、画像の重さではありません）。
• 4 つのサブパート: TTFB（約 40 %）、リソース読み込み遅延（<10 %）、リソース読み込み時間（約 40 %）、要素レンダリング遅延（<10 %）— web.dev はこれらをガイドラインと呼び、固定の割合ではありません。正確な割合を追うのではなく、ページごとに診断してください。CrUX 2025 データ: 画像のダウンロードは多くの場合最小の部分 — そのため「画像を圧縮するだけ」では間違った問題を修正することがよくあります。
• 主な修正: LCP 画像を遅延読み込みしない。実際の候補に fetchpriority="high" を追加する。HTML にない場合はプリロードする（プリロードと fetchpriority は異なる問題を解決します — 習慣で両方を使わないでください）。レンダリングをブロックする CSS/JS を削減する。TTFB を減らす。
• ラボではなくフィールド。 CrUX/Search Console がランキングを左右します。Lighthouse は近似値にすぎず、より厳しいデスクトップしきい値（≤ 1,2 秒）を使用します。現在の LargestContentfulPaint API はドキュメントの読み込みに限定されており、bfcache の復元や同一ドキュメントの SPA ナビゲーションではリセットされません。
• ランキング: Google は CWV フィードのランキングシステムを確認していますが、正確な LCP の重みは公開しておらず、タイブレーカーとも呼んでいません。コンテンツの関連性が依然として支配的です。改善が最も難しい CWV であり、モバイルではさらに困難です。

公式ドキュメント

Google の Chrome および Search チームによる一次情報のガイダンス。

web.dev（Chrome チーム）

• Largest Contentful Paint (LCP) — 標準的な定義: LCP 要素としてカウントされるもの、サイズの計算方法、レポートが停止するタイミング、測定 API。
• Optimize Largest Contentful Paint — 4 つのサブパートのフレームワークと完全な最適化プレイブック。
• Core Web Vitals — 3 つの Core Web Vitals の中で LCP がどこに位置するか。
• How the Core Web Vitals metrics thresholds were defined — 2,5 秒の基準の背後にある調査と達成可能性データ。

Chrome for Developers

• LCP image subparts and RTT now available in CrUX — 2025 年 2 月のフィールドデータリリースで、4 つのサブパート（画像 LCP のみ）が利用可能になりました。
• Largest Contentful Paint | Lighthouse — ラボ指標とそのデバイス固有のスコアリング。

Google Search Central

• Understanding Core Web Vitals and Google search results — Core Web Vitals が検索にどのように関与するか。

ソースからの引用

Google のドキュメントとチームからの公式声明。各リンクは、引用した箇所にジャンプするディープリンクです。

web.dev — 定義と動作 (Philip Walton & Barry Pollard, Google)

• “LCP reports the render time of the largest image, text block, or video visible in the viewport, measured relative to when the user first navigated to the page.” (翻訳) 「LCPは、ユーザーが最初にページへ移動した時点を基準として、ビューポートに表示されている最大の画像、テキストブロック、または動画のレンダリング時間を報告します。」 引用へ移動
• 測定対象について: “LCP doesn’t consider margins, paddings, or borders applied using CSS.” (翻訳) 「LCPは、CSSで適用されたマージン、パディング、またはボーダーを考慮しません。」 引用へ移動
• レポートの停止タイミングについて: “The browser will stop reporting new entries as soon as the user interacts with the page (via a tap, scroll, or keypress), as user interaction often changes what’s visible to the user.” (翻訳) 「ユーザーがページを操作（タップ、スクロール、キー押下）すると、ブラウザは新しいエントリの報告をすぐに停止します。ユーザーの操作によって、ユーザーに表示される内容が変わることが多いためです。」 引用へ移動
• タイミングに含まれるものについて: “It is important to note that LCP includes any unload time from the previous page, connection set up time, redirect time, and other Time To First Byte (TTFB) delays.” (翻訳) 「LCPには、前のページのアンロード時間、接続確立時間、リダイレクト時間、その他のTime To First Byte（TTFB）遅延が含まれることに注意することが重要です。」 引用へ移動

web.dev — 最適化 (Philip Walton & Barry Pollard、Google)

• 最も重要な遅延読み込みのルール: “Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay.” (翻訳) 「LCP画像を遅延読み込みしないでください。常に不要なリソース読み込み遅延につながるためです。」 引用へ移動
• サブパート目標の背後にある原則: “The vast majority of the LCP time should be spent loading the HTML document and LCP source.” (翻訳) 「LCP時間の大部分は、HTMLドキュメントとLCPソースの読み込みに費やされるべきです。」 引用へ移動

Google Search Central — ランキング

• “We highly recommend site owners achieve good Core Web Vitals for success with Search and to ensure a great user experience generally.” (翻訳) 「サイト所有者が検索での成功と、一般的に優れたユーザーエクスペリエンスを確保するために、優れたCore Web Vitalsを達成することを強くお勧めします。」 （Search Central Core Web Vitalsドキュメントから転載。最終的なものとして扱う前に、ライブページで確認してください。）

LCP修正チェックリスト

おおまかに上から下へ進めてください。発見とTTFBを最初に。通常、これらが最も大きく、最も頻繁に壊れているレバーだからです。

• 実際のLCP要素を特定した（PageSpeed Insightsの診断、DevToolsのパフォーマンスパネル、またはweb-vitalsライブラリ）— 盲目的に最適化しない。
• 4つのサブパートを確認し、何かを変更する前にどれがボトルネックかを判断した。
• LCP画像がloading="lazy"ではない（遅延読み込みはファーストビューの下のみ）。
• LCP画像に**fetchpriority="high"**が設定されている。
• LCP画像が初期HTMLで検出可能である — またはCSS/JSで読み込まれる場合はプリロード（<link rel="preload">）されている。
• ヒーロー画像をJavaScriptで読み込んでいない（プリロードスキャナーから隠れる）。
• レンダリングをブロックするCSSを最小化/インライン化し、重要でないスタイルは遅延させた。
• <head>内に同期スクリプトがない。長いタスクを分割した。
• 最新の画像形式（WebP/AVIF）、適切な圧縮、優れたCache-Controlを持つCDN経由で配信。
• ファーストビューの下の画像は遅延読み込みし、LCP画像と帯域幅を競合させない。
• TTFBに対処：リダイレクトを最小化、サーバーレスポンスを最適化、不要なURLパラメータを削除。
• テキストLCP？ font-display: optionalまたはシステムフォントを使用し、スワップされるフォントファイルをプリロードする。
• フィールドデータ（CrUX / Search Console）で検証した。Lighthouseのラボ実行だけでなく。

LCPチートシート

しきい値（実ユーザーの75パーセンタイル、デバイス別）

4つのサブパート — それぞれの内容と修正方法

LCP要素になり得るもの

• <img> · <svg>内の<image> · <video>ポスター · CSS background-image: url() · ブロックレベルテキスト

ヒューリスティックで除外: opacity: 0、全ビューポートの「背景」要素、低エントロピーのプレースホルダー。

豆知識

• LCPはフィールド指標（CrUX / Search Consoleがランキングに影響）であり、Lighthouseは近似値に過ぎず、デスクトップのGoodはより厳しい**≤ 1,2 s**を使用。
• LCP要素は読み込み中に変化することがあり、ユーザー操作前の最後の候補がカウントされる。
• 約4ページ中3ページは画像LCPで、残りはテキスト（フォントがレバー）。
• 画像のダウンロード時間は多くの場合最小のサブパートであり、圧縮が常に答えとは限らない。
• LCP ≠ FCP、LCP ≠ ページ全体の読み込み時間。

LCPの測定と修正のためのツール

フィールドデータ（ランキングに使用されるもの）

• PageSpeed Insights — フィールドタブで実ユーザーのCrUX LCPを表示。診断でLCP要素をフラグ。
• Search Console — Core Web Vitalsレポート — 実ユーザーデータに基づき、URL全体のLCPステータスをグループ化して表示。
• Chrome User Experience Report（CrUX） — 基盤となるフィールドデータセット。2025年2月時点でAPI経由で4つの画像LCPサブパートを含む。
• web-vitals JSライブラリ — 自社の実ユーザーモニタリングからLCPとLCP要素をログ。

ラボデータ（デバッグ用）

• Lighthouse — 迅速なラボLCPと改善機会リスト（フィールドより厳しいデスクトップしきい値に注意）。
• Chrome DevTools — パフォーマンスパネル — LCPノードと完全なレンダリングタイムラインをマーク。
• WebPageTest — どのサブパートが遅いかを特定するためのウォーターフォールビュー。

SEOクローラー

• Ahrefs Site Audit — サイト全体のCore Web Vitals / パフォーマンス問題を大規模に表面化。

ツール自体のスコアリング方法

このページが説明する指標の実例 — よく知られたページ速度およびモニタリングサービスが、自社の実ユーザーモバイルLCP（Chrome UX Reportフィールドデータ）でランク付けされたもの：

LCP修正が間違った問題を対象にしている場合

ヒーロー画像の遅延読み込み

loading="lazy" は、LCPになる可能性が高いファーストビュー内の画像の発見を遅らせます。画像を即時読み込みし、可能性の高い候補に fetchpriority="high" を指定し、遅延読み込みはファーストビュー外の画像に限定してください。

ボトルネックを見つける前にすべての画像を圧縮する

画像のダウンロード時間はLCPの4つのサブパートの1つに過ぎず、最も小さい場合もあります。修正を選ぶ前に、LCP要素を特定し、TTFB、読み込み遅延、読み込み時間、レンダリング遅延を調査してください。

JavaScriptによるヒーロー画像の読み込み

JSで注入された画像は、ブラウザのプリロードスキャナーからURLを隠し、リソースの読み込み遅延を生み出します。画像を初期HTMLに配置するか、CSSやJSが画像を管理する必要がある場合はプリロードしてください。

1回のLighthouse実行で勝利を宣言する

Lighthouseは管理された診断ツールですが、GoogleのCWV判定はCrUXのフィールドデータに基づいています。ラボ実行でメカニズムを検証し、実際のユーザーデータでp75の結果が改善したかどうかを待って確認してください。

LCPリソースの開始が遅い

症状: TTFBとLCPリソースリクエストの間に長いギャップが現れます。考えられる原因: 遅延読み込み、JSによる発見、CSS背景画像、または低いフェッチ優先度。修正: リソースを初期HTMLで発見可能にし、遅延読み込みを削除し、fetchpriority="high" を適用するか、プリロードしてください。トレースでリクエストが早く移動することを確認してください。

リソースは読み込まれるがLCPがまだ遅く発生する

症状: 読み込み時間がLCPイベントよりかなり前に終了します。考えられる原因: レンダリングブロックCSS、同期JavaScript、長いタスク、またはテキストLCPのフォントレンダリング。修正: ブロックする作業を減らし、テキストのフォント戦略をテストし、要素のレンダリング遅延が縮小することを確認してください。

ラボLCPは良好だがフィールドLCPは不良

症状: Lighthouseは合格するが、CrUXやSearch Consoleは合格しない。考えられる原因: 実際のユーザーは異なるデバイス、ネットワーク、キャッシュ状態、地理、またはLCP要素を持っています。修正: フィールドデータをセグメント化し、RUMの要素/サブパートの詳細を取得し、デフォルトのラボプロファイルだけを調整するのではなく、遅いセグメントを再現してください。

報告されるLCP要素が実行間で変化する

症状: DevToolsが異なる画像やテキストブロックを識別します。考えられる原因: レスポンシブブレークポイント、パーソナライゼーション、遅いDOM変更、または競合する候補。修正: 代表的なビューポートと状態をテストし、1つのデスクトップヒーローがすべてのユーザーをカバーすると想定せずに、繰り返し発生する各候補を最適化してください。

ヒーロー画像の発見: 遅延 vs 早期

簡略化された遅延実装は画像をJavaScriptの背後に隠します:

<div id="hero"></div>
<script>
  document.querySelector('#hero').innerHTML = '<img src="hero.webp" alt="">';
</script>

ブラウザはHTMLの解析中にこのバージョンを発見して優先順位を付けることができます:

<img src="hero.webp" alt="" fetchpriority="high" width="1200" height="675">

CSS背景画像: 非開示 vs プリロード

LCP画像をCSS背景のままにする必要がある場合は、スタイルシートが終了する前に開示してください:

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

プリロードは、そのURLとリクエスト属性が実際のリソースと一致する場合にのみ役立ちます。

Chrome DevToolsで最近のLCP候補を一覧表示する

これをChrome DevToolsコンソールに貼り付け、ページを再読み込みし、ブラウザが報告する各候補を確認してください。インタラクション前の最後の候補が関連するものです。

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.table({
      lcp: Math.round(entry.startTime),
      element: entry.element?.tagName,
      url: entry.url || '',
      size: entry.size,
    });
  }
}).observe({ type: 'largest-contentful-paint', buffered: true });

遅延読み込みされる可能性が高いファーストビュー内の画像を見つける

これをDevToolsコンソールで実行してください。現在のビューポート内で上端が始まる遅延画像を一覧表示します。属性を削除する前に実際のLCP候補を確認してください。

[...document.querySelectorAll('img[loading="lazy"]')]
  .filter((img) => img.getBoundingClientRect().top < innerHeight)
  .map((img) => ({ src: img.currentSrc || img.src, top: img.getBoundingClientRect().top }));

クローラーで画像の優先度属性を抽出する

Screaming Frogのカスタム抽出でこのXPathを使用して、高優先度としてマークされた画像を返します:

//img[@fetchpriority='high']/@src

LCP修正が適用されたことを証明する

発見順序テスト

実行するテスト: ヒーロー画像を変更した後、DevToolsパフォーマンストレースを記録します。期待される結果: LCPリクエストが早く開始され、遅延読み込みされない。失敗の解釈: リソースが隠れたまま、優先度が下がったまま、または別の依存関係の背後でブロックされたまま。監視期間: 即時のラボ結果。ロールバックトリガー: 変更が別の重要なリソースを遅らせるか、ラボLCPを一貫して悪化させる。

レンダリング遅延テスト

実行するテスト: 同等のbefore/afterトレースでLCPリソース完了とLCPイベントを比較します。期待される結果: 新しいレイアウトや視覚的回帰なしに要素レンダリング遅延が縮小します。失敗の解釈: CSS、JavaScript、またはフォントがまだ描画をブロックしています。監視期間: 代表的なビューポートで即時。ロールバックトリガー: レンダリングの破損、スタイルの欠落、または悪化する再発性LCP。

フィールドアウトカムテスト

実行するテスト: デプロイ後にURLレベルのCrUXまたはファーストパーティRUMのp75 LCPを監視します。期待される結果: p75がGoodしきい値に向かって移動するか、その範囲内に留まり、INPやCLSを悪化させません。失敗の解釈: ラボのケースが代表的でないか、別のサブパートが実際の訪問を支配しています。監視期間: RUMが先行できます。CrUXは28日間のローリングウィンドウが入れ替わる必要があります。ロールバックトリガー: リリースに関連する持続的なフィールド回帰。

追跡する価値のあるLCPメトリクス

フィールドp75 LCP

メトリクス: フォームファクター別の75パーセンタイルでのLCP。それが示すもの: 実際のユーザーがCore Web Vitalsの読み込みしきい値を満たしているかどうか。取得方法: CrUX、Search Console、またはファーストパーティRUM。ベンチマーク/現実的な範囲: Goodは2,5秒以下。モバイルとデスクトップをセグメント化します。頻度: 毎週、CrUXのローリングウィンドウを記録します。

LCPサブパート分布

メトリクス: LCPのTTFB、リソース読み込み遅延、読み込み時間、要素レンダリング遅延。それが示すもの: どのステージが待ち時間を所有しているか。取得方法: 代表的なラボトレースと、利用可能な場合はCrUX/RUMからの画像LCPサブパート。ベンチマーク/現実的な範囲: 記事のおおよその40/10/40/10診断分割をガイドとして使用しますが、普遍的なパフォーマンスの約束ではありません。頻度: テンプレートリリース後、優先テンプレートでは毎月。

Good-LCP URLカバレッジ

メトリクス: GoodフィールドLCPを持つ重要なURLグループ。それが示すもの: 改善が広範囲か、サンプルページに限定されているか。取得方法: Search ConsoleのCWVグループと、優先ページのURLレベルCrUX。ベンチマーク/現実的な範囲: テンプレートごとにベースラインを確立します。低トラフィックのURLには個別のフィールドデータがない場合があります。頻度: 毎週。

自分でテスト: Largest Contentful Paint

LCPの測定と診断に関する5つのクイッククエスチョン。各質問に回答を選び、確認してください。

時間をかける価値のあるリソース

関連する私の記事

• What Is Largest Contentful Paint (LCP) & How To Improve It — Ahrefsブログでの完全なLCPガイド。
• What Are Core Web Vitals (CWVs) & How To Improve Them — LCPがINPやCLSとどう関係するか、そしてなぜ修正が最も難しいか。
• The Beginner’s Guide to Technical SEO — ページパフォーマンスが全体像の中でどこに位置するか。

公式 (Google / Chrome)

• Largest Contentful Paint (LCP) と Optimize LCP — 標準的なペア。
• How CWV thresholds were defined — 2,5秒の背後にある理由。

その他の情報源

• Fix your website’s Largest Contentful Paint by optimizing image loading — MDNの開発者向け視点。帯域幅の競合とJS画像アンチパターンに強い内容です。
• Performance — 2025 Web Almanac — HTTP Archiveの年次詳細レポート。fetchpriority、preloadの使用状況、画像とテキストのLCPの内訳、デバイス別の合格率に関する採用統計の出典です。
• Largest Contentful Paint (LCP) — DebugBearのドキュメントでは、サブパーツを特定するためのウォーターフォール分析、プログレッシブJPEGの注意点、iframe/ソフトナビゲーションのエッジケースを扱っています。
• Largest Contentful Paint (LCP): What It Is, How to Measure & Optimize — corewebvitals.io。実際のRUMベンチマーク、ビジネス影響のケーススタディ（Vodafone Italy）、Google Flightsのfetchpriorityの結果を掲載。
• Largest Contentful Paint | MDN Web Docs — LargestContentfulPaint API、要素タイプ、ブラウザ互換性に関するMDNリファレンス。

引用に値する統計

• LCPは合格が最も難しいCore Web Vitalです。 構成要素が最も多いため、INPやCLSよりもサイトが苦戦する原因となっています。 出典
• モバイルはデスクトップより難しいです。 CPUと接続が遅いとLCPが上昇し、3G/低速接続では2,5秒のしきい値を達成するのはほぼ不可能です。 出典
• 画像のダウンロード時間は、LCPの中で最も小さい部分であることがよくあります。 ChromeによるHTTP Archiveデータの分析では、ダウンロード時間がボトルネックになることはあまりなく、通常はTTFBと発見の遅延が原因であることが判明しました。 出典
• CrUXのカバレッジは薄いです。 4200万ページを対象とした当社の調査では、関連するCrUXフィールドデータを持つページは約11,4%のみで、ほとんどのページは測定に十分な実ユーザートラフィックを得られていません。 出典
• モバイルページの62%がGood LCPを達成しているのに対し、デスクトップページは74%です（2025 Web Almanac）。モバイルのギャップは、CPUとネットワーク接続の遅さを反映しています。 出典
• LCP要素が画像であるページが76%あるにもかかわらず、LCP画像をプリロードしているモバイルページはわずか2,1%です — これは大きな最適化の機会損失です（2025 Web Almanac）。 出典
• fetchpriority="high"の採用は、2022年のモバイルサイトの0,03%から2025年には17,3%に増加しました。これは主にWordPressコアがこれを追加したことによるものです（2025 Web Almanac）。Google Flightsでは、この単一の属性によりLCPが700ミリ秒改善しました。 出典

動画

• Google Search Central（YouTube）— Core Web Vitalsとページエクスペリエンスの解説動画。ChromeチームによるLCP最適化のウォークスルーも含まれます。 チャンネル

変更履歴