言語

Largest Contentful Paint (LCP) とSEO

LCPが測定するもの、そのしきい値、それを構成する4つのサブパート、そして実際に改善する方法 — 人々が最も苦労するCore Web Vitals。

初回公開：2026年6月26日 · 最終更新：2026年8月3日 · 上級者向け
AI執筆者：AI v2

Largest Contentful Paint (LCP) は、ページの読み込み開始時点から見て、ビューポート内で表示される最大の画像またはテキストブロックのレンダリング時間です。良好な値は、実ユーザーの75パーセンタイルで2,5秒以下です。これはCore Web Vitalsの3つのうちの1つです。LCPは4つのサブパート（TTFB、リソース読み込み遅延、リソース読み込み時間、要素レンダリング遅延）に分けられ、通常はTTFBと読み込み時間が支配的です。最大の改善策は、LCP画像を遅延読み込みしないこと、fetchpriority=highを指定すること、プリロードすること、レンダリングをブロックするリソースを削減すること、そしてTTFBを改善することです。これはフィールドメトリクスであり、ラボツールは近似値しか提供しません。Core Web Vitalsの中で、特にモバイルで最も合格が難しい指標です。

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秒なのか

バケットLCP
良好≤ 2,5 秒
改善が必要2,5 秒 – 4,0 秒
不良> 4,0 秒

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

この主張の根拠 A good LCP is 2.5 seconds or less at the 75th percentile of page loads, segmented by device type. 対象範囲： Current web.dev LCP field threshold and assessment method. 信頼度： 高 · 検証日： web.dev: Largest Contentful Paint

なぜ具体的に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サブパート全LCP時間に占める典型的な割合
Time to First Byte約40%
リソース読み込み遅延< 10%
リソース読み込み時間約40%
要素レンダリング遅延< 10%

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

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

この主張の根拠 An LCP image should not be lazy-loaded, and reducing resource load delay is a primary LCP optimization. 対象範囲： web.dev guidance for image-based LCP elements. 信頼度： 高 · 検証日： web.dev: Optimize LCP
LCPを4つの連続するサブパートに分割し、意図した割合を超えて消費しているパートを最適化します。 出典： web.dev

タイムラインはTime to First Byteから始まり、LCP全体の約40%を目標とします。リソース読み込み遅延は続き、10%未満に保つ必要があります。リソース読み込み時間は約40%を目標とします。要素レンダリング遅延は10%未満に保つ必要があり、最大の要素が実際に描画されるときに終了します。

© Patrick Stox LLC · CC BY 4.0 ·

そして、一般的な前提を覆す点があります。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が隠れるため、まさにアンチパターンです。
  • 重要なリソースを同一オリジンでホストし、ブラウザが余分な接続設定を支払わないようにします。
この主張の根拠 An LCP image should not be lazy-loaded, and reducing resource load delay is a primary LCP optimization. 対象範囲： web.dev guidance for image-based LCP elements. 信頼度： 高 · 検証日： web.dev: Optimize LCP

プリロードと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を最適化するのは、表示が速いページがユーザー（およびコンバージョン）にとって本当に良いからです。メカニズムがランキングのタイブレーカーとして文書化されているからではありません。実際にはそうではないからです。

この主張の根拠 Google says Core Web Vitals are used by ranking systems, but current documentation does not specify an LCP weight, tiebreaker rule, or ranking guarantee. 対象範囲： ranking systems 信頼度： 高 · 検証日： Understanding page experience in Google Search results

データからのいくつかの現実: 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）で確認できます。それぞれがこのクラスター内の個別の詳細ガイドです。

専門家メモを追加

専門家の引用を固定

新しい人物ですか？まず、 /admin/experts/ → 専門家の引用を固定 から未登録プロフィールを作成してください。