Largest Contentful Paint（LCP）：概要、計測方法、改善方法

Largest Contentful Paint（LCP）とは

Largest Contentful Paintは、画面の表示領域内に描画される最大のコンテンツ要素（画像、動画、テキストブロック）のレンダリング時間です。LCP値は、ページをリクエストしてからその要素がファーストビューに表示されるまでの時間をミリ秒単位で表したものです。

「last contentful paint」と呼ばれることもありますが、対象となるのはあくまで最大の要素です。後から描画された要素が小さければ、LCPは変わりません。

Largest Contentful Paintの経緯

なぜ読み込み速度を「ページの読み込みにかかる時間」として計測しないのでしょうか。

現代のWebサイトの大半では、ページの読み込み完了タイミングを定義できないからです。lazy loadingやプログレッシブローディングによって、訪問者が滞在している限り読み込みが続くこともあります。単一の時点だけでは、ページの速度を表せません。

ページの読み込み中、遅さを感じるタイミングはいくつかあります。サーバーの応答が遅い場合（Time to First Byte）、しばらく画面に何も表示されない場合（First Contentful Paint）、他の要素が出揃ってもヒーロー部分がグレーの枠のままの場合（Largest Contentful Paint）などです。最初のクリックに何も反応しないこともあります。

LCPが採用されたのは、訪問者の視覚的な体験に即しているからです。LCPが発生した時点で、スクリプトがまだ実行中であっても、大半の訪問者はページの読み込みが終わったと感じます。この指標は、「ページのコンテンツはいつ表示されるのか？」という1つの問いに答えるために作られました。

LCPとFCPの違い

Largest Contentful Paint（LCP）とFirst Contentful Paint（FCP）は、どちらも読み込みパフォーマンスを計測しますが、着目するタイミングが異なります。FCPは、小さなナビゲーションバーやローディングスピナーなど、ブラウザがコンテンツの最初の1ピクセルを描画した瞬間に記録されます。一方のLCPは、viewport内に意味のある最大の要素がレンダリングされたときに記録されます。

FCPはページの読み込みが始まったことを示します。LCPはページの読み込みが完了したように感じられることを示します。GoogleがLCPをCore Web Vitalsに採用したのはそのためです。

大半のWebサイトでは、まずLCPの改善から着手してください。FCPは常にLCPより前に発生するため、LCPが速ければ通常はFCPも速くなります。一方で、FCPが速くてもLCPが速いとは限りません。ヘッダーが0.8秒で描画されても、ヒーロー画像の表示に4秒かかるページもあるからです。

LCPが重要な理由

Core Web Vitalsの1つであるLCPは、SEOの観点で重要です。しかし、訪問者にとってはさらに重要です。待たされるのを好む人はいませんし、トラフィックの大半を占めるモバイルでは読み込みがさらに遅くなるためです。

• 検索順位。LCPはGoogleのCore Web Vitalsに含まれており、Googleはページ速度をランキング要因として使用しています。
• 訪問者。真っ白な画面や、ヒーロー画像があるべき場所のグレーの枠を見せられた訪問者は離脱します。後述するVodafoneのテストがその数字を証明しています。
• Google Ads。ランディングページの利便性は品質スコアの一部です。ランディングページが遅いと、1クリックあたりの費用が高くなります。

事例：Vodafone（LCPを31%改善、売上が8%増加）

Vodafone Italyは、従来のランディングページと、見た目も動作も同じで高速化したページの2つでトラフィックを50対50に分割テストしました。高速化したページでは、クライアント側のウィジェットではなくサーバー側でレンダリングを行い、リサイズしたヒーロー画像を配信し、ファーストビューより下の画像を遅延読み込みさせ、SVGとPNGのファイルサイズを削減しました。その結果、LCPは8.3秒から5.7秒へと31%短縮され、売上が8%増加しました。（web.devのVodafone事例紹介）

テスト：Google Flights（fetchpriorityで700ms短縮）

Google Flightsのページで行われたテストでは、LCP画像にfetchpriority="high"を追加したことで、LCPが2.6秒から1.9秒に短縮されました。これを指定しない場合、Chromeは低優先度で画像をリクエストし、レイアウト計算によって画像がviewport内にあると判明して初めて優先度を引き上げます。負荷の高いページでは、これだけで数百ミリ秒の待機時間が発生します。詳細については、Core Web Vitalsのリソース優先順位付けを参照してください。

どの要素がLCPの対象になるのか？

すべての要素がLCP要素になれるわけではありません。ユーザーがページを操作する前に、画面の表示領域（viewport）内に描画されている必要があります。

対象となる要素は以下の通りです。

• <img>要素。
• <svg>要素内にネストされた<image> 要素。
• <video>要素（ポスター画像 または最初の動画フレームのいずれか早い方が使用されます）。
• CSSの url()関数で読み込まれた背景画像を持つ要素。これも対象になりますが、preload scannerが検出できないため、ブラウザが画像を見つけるのが遅れます。詳細は背景画像の遅延読み込みを参照してください。

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

対象外となる要素もあります。opacity: 0が指定された要素、viewport全体を覆う画像（Chromeはこれらを背景として扱います）、低エントロピー画像です。Chrome 112以降、表示ピクセルあたりの画像データが0.05ビット未満の画像は、プレースホルダーとして無視されます。なお、Chromeはこれらのルールを随時変更しています。

LCP要素のサイズはどう計測されるのか

ブラウザは以下のルールに基づいて各候補のサイズを計算します。

• viewport内のみ：ページの表示領域のみが対象になります。要素の一部のみがviewport 内にある場合、対象サイズはその部分だけに切り取られます。
• ボーダー、パディング、マージンは除外：すべての要素において、テキストや画像のボーダー、パディング、マージンは 完全に無視されます。
• テキストのサイズ：テキスト要素は、テキストノードを囲むことができる 最小の矩形として報告されます。
• 画像のサイズ：画像の場合、本来の寸法（元の幅と高さ） と表示サイズ（画面上のサイズ）のいずれか小さい方が、LCP要素のサイズ計算に使用されます。
• 最初のサイズを採用：レイアウトの変化や要素サイズの変更があった場合でも、 LCPで考慮されるのは最初のサイズのみです。
• 削除された要素も対象：要素がDOMから削除された場合でも、その要素は引き続きLCP 候補として扱われます。

LCP要素は読み込み中に変化する

ページは段階的にレンダリングされるため、読み込み中にLCP要素が頻繁に変わります。最初のユーザー操作があるまで、ブラウザは新しいLCP候補を都度報告します。viewport内に表示され、直前の候補よりも大きな要素が新たに描画されると、それが新しいLCP要素になります。

LCPのfield dataからわかること：CoreDashでは1日に数百万件のLCPエントリを追跡しています。モバイルでは、段落や見出しがLCP要素になることがよくあります。デスクトップではviewportが広いため大きな画像が収まり、同じページでもデバイスによってLCP要素が異なるケースが多々あります。何を修正するか決める前に、両方を確認してください。

良好なLCPスコアとは

Core Web VitalsのLCPの評価に合格するには、アクセスの75%以上で「良好」（2.5秒未満）を達成する必要があります。2.5秒〜4秒は「改善が必要」、4秒を超えると「不良」です。まずはPageSpeed Insightsのモバイルタブを確認してください。上部に表示されるfield dataは、過去28日間のp75の値です。

CoreDashのデータからわかること

画像LCP vs テキストLCP

画像がLCP要素のページはp75のLCPが744msで、テキストがLCP要素のページ（388ms）のほぼ2倍遅くなっています。この差の大部分は、ブラウザが画像を発見してリクエストするタイミングの遅さに起因しています（後述する4つのフェーズを参照）。

プリロードとlazy loadingの影響

プリロードされたLCP画像はp75が364msで、「不良」と判定されたページの読み込みはゼロでした。一方、lazy loadingされたLCP画像は720ms（4.3%が「不良」）、プリロードされていない画像は752msでした。LCP画像は絶対にlazy loadingしないでください。そして、HTML内でfetchpriority="high"を指定するか、それが不可能な場合はプリロードして、早期にリクエストされるようにしてください。

モバイル vs デスクトップのLCP

モバイルのLCP（75パーセンタイルで764ms）は、デスクトップのLCP（380ms）の2倍です。モバイル回線は遅く、スマートフォンはCPU性能が劣るためです。Googleはモバイルとデスクトップを個別に評価しますが、大半のサイトがつまずくのはモバイルです。まずはモバイルから着手してください。

Web全体のLCP状況

2026年8月のCrUXリリースでは、良好なLCPを達成したオリジンは68.1%で、前年の66.7%から微増しました。それでもCore Web Vitalsの3指標の中では依然として最も低い数値です（INPは85.3%、CLSは81.5%）。そのため、多くのサイトにとって、LCPが合格できるかどうかの分かれ目になります。

HTTP Archiveのクロールデータは、CrUXでは収集されない詳細を補ってくれます。2025 Web Almanacによると、モバイルページの76%でLCP要素が画像であり、約16%のページでその画像がlazy loadingされていました。LCP画像を持つモバイルページのうち、fetchpriority="high"を使用しているのはわずか17%で、プリロードしているのは約2%にとどまります。

LCPの計測の仕組み：4つの重要フェーズ

Googleによると、Largest Contentful Paintは4つのフェーズ（サブパート）に分解できます。フェーズごとに対策が異なるため、まずはどのフェーズが遅いのかを突き止めてください。Time to First Byte（TTFB）が遅いならサーバー側の改修が必要ですが、Resource Load Delayが長いならHTMLの修正が必要です。

LCPの時間は、以下の4つのフェーズの合計です。

• Time to First Byte (TTFB)：サーバーの応答時間です。DNSルックアップからTCP/TLS接続を経て、ブラウザがHTMLドキュメントの最初の1バイトを受信するまでのすべてが含まれます。TTFBが遅いと、後続のすべての処理が後ろ倒しになります。主な原因はHTMLがキャッシュされていないことで、アクセスがあるたびにPHPやNodeでページを再構築しているケースです。HTMLをキャッシュしていないCDNは、画像を高速化するだけです。
• Resource Load Delay：TTFBの完了から、ブラウザが実際にLCPリソースのダウンロードを開始するまでの時間です。ここでの遅延が長い場合、ブラウザがLCPリソースを発見するのが遅かったことを意味します。主な原因は、CSSの背景画像（preload scannerが検出できない）やクライアントサイドレンダリング（JavaScriptの実行後にしかLCP要素が現れない）です。LCP要素は最初のHTMLに配置し、それが不可能な場合に限りLCP画像をプリロードしてください。
• Resource Load Duration：LCPリソース（画像、フォント、動画）のダウンロードにかかる時間です。このフェーズはファイルサイズとネットワーク環境に左右されます。AVIFやWebPの採用、スマートフォン向けに適切なサイズの画像を配信するsrcsetの設定が対策になります。大半のサイトにおいて、4つのフェーズの中で最も短い時間で済みます。
• Element Render Delay：LCPリソースのダウンロード完了から、要素が画面上に完全にレンダリングされるまでの時間です。画像データは届いているのに、ブラウザがまだ描画できない状態を指します。render blockingなCSSやmain threadを占有するJavaScriptが主な原因です。テストスクリプトが読み込まれるまでページ全体を非表示にするA/Bテストスニペットは、その典型例です。

GoogleはLCPが画像である実際のChromeナビゲーションを調査し、p75のLCPをこれら4つのフェーズに分解しました。各グループの中央値となるオリジンの数値は以下の通りです。

LCPが「不良」のサイトでは、TTFBとload delayだけで3.5秒以上を消費しています。画像のダウンロードにかかる時間は350msです。LCPが「不良」なオリジンの大半において、LCP画像のダウンロードに費やされている時間はLCP全体の10%未満にすぎません。

各フェーズを特定して修正する手順については、Largest Contentful Paint（LCP）問題の特定と改善手順を参照してください。

LCPでよくある間違い

間違い1：LCP画像をlazy loadingしている

loading="lazy"は、画像がviewportの近くに来るまでダウンロードを待機するようブラウザに指示します。LCP画像は最初からviewport内にあるため、ブラウザはレイアウト計算を行ってそれを確認してからでないとダウンロードを開始できません。テーマやページビルダーは、ヒーロー画像を含むすべての画像にこれを付加しがちです。LCP画像からこの属性を削除してください。やるべきことはそれだけです。2025 Web Almanacによると、約16%のページがこの過ちを犯しています。詳細はlazy loadingされたLCP画像の修正方法を参照してください。

間違い2：LCP画像の発見が遅い

スライダーやクライアントサイドレンダリングされたヒーロー画像は、CSSのパースやJavaScriptの実行が終わって初めて画像のURLがページに挿入されます。これにより、ダウンロードが始まるまでに数百ミリ秒のロスが生じます。最も確実な対策は、HTML内に通常の<img>を記述することです。それが不可能な場合は、<head>にプリロードのヒントを追加してください。

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

これでブラウザは即座にダウンロードを開始します。プリロード単体では優先度は上がらないため、必ずfetchpriority="high"を併用してください。そうしないと、画像はスタイルシートやスクリプトの後回しにされてしまいます。詳細はLCP画像のプリロードガイドを参照してください。

間違い3：LCP要素にCSS背景画像を使っている

preload scannerはbackground-image: url(...)を検出できません。ブラウザはHTMLとCSSをダウンロードし、そのスタイルルールをページ上の要素とマッチングさせて初めて画像を見つけます。これがResource Load Delayを増大させます。解決策は、代わりに標準の<img>タグを使用し、fetchpriority="high"属性を付与することです。

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

これでpreload scannerがHTML内から画像を発見し、fetchpriority="high"によってリクエストキューの先頭に配置されます。詳細はリソースの優先順位付けガイドを参照してください。

Largest Contentful Paintの計測方法

JavaScriptでLargest Contentful Paintを計測する

最も手軽な方法はPerformanceObserverを使うことです。以下のスニペットで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 });

簡易的な確認以上の計測を行う場合は、Web Vitals Libraryを使用してください。

Chrome DevToolsでLargest Contentful Paint（LCP）を計測する

1. Ctrl+Shift+I（MacではCmd+Option+I）を 押してChrome DevToolsを開きます。
2. Performanceパネルを開きます。現在のページのLCPとLCP要素がすぐに表示されます。
3. パネル内のリロードボタンをクリックしてトレースを記録します。トレース内のLCPマーカーに、LCP要素と4つのフェーズが表示されます。

トレースで確認すべきポイントを含む詳細な解説は、Chrome DevToolsによるLCPの診断を参照してください。

ラボツールとフィールドツールでLargest Contentful Paintを計測する

lab dataとfield dataは役割が異なります。両方が必要です。

• field data（RUMおよびCrUX）は、Googleが評価をクリアしたかを判定するために使用するデータです。実際のユーザーが体験している値そのものです。まずはここを確認し、問題があるかどうかを把握してください。
• lab data（Lighthouseなど）は、制御された環境でのテスト結果です。Googleがランキング要因として使うことはありませんが、デバッグには不可欠です。問題が起きている原因を教えてくれます。

各ツールの特徴：

Largest Contentful Paintの改善

モバイルで最も遅いテンプレートを取り上げ、LCPの4つのフェーズを確認してください。CoreDashなら実際の訪問者ごとのデータをページ単位で確認でき、DevToolsなら単一の読み込みについて確認できます。前述のfield dataが示す通り、LCPが「不良」なほぼすべてのサイトにおいて、TTFBとload delayがボトルネックの大半を占めています。まずはそこから着手してください。

誰もが真っ先に試すのが、ヒーロー画像をAVIFに変換することです。しかし、LCPが4秒のサイトでも、ダウンロード全体にかかっている時間は約350msにすぎません。ファイルサイズを削減しても、短縮できるのはそのごく一部です。やるべき施策ではありますが、最後に取り組んでください。

フェーズごとの対策：

• TTFB: サーバーまたはCDNでHTMLをキャッシュします。詳細は TTFB最適化ガイドを参照してください。
• Resource Load Delay: HTMLに<img>を記述し、loading="lazy"を外してfetchpriority="high"を指定します。Resource Load Delayの改善方法を参照してください。
• Resource Load Duration: デバイスに合わせたサイズでファイルサイズを削減します。LCP画像の最適化方法を参照してください。実際のプロジェクトでLCPを70%短縮した事例も確認できます。
• Element Render Delay: render blockingなCSSの削減、スクリプトの遅延読み込み、アンチフリッカースニペットの排除を行います。Element Render Delayの改善方法を参照してください。

関連ガイド

LCPの各パートに対応した個別ガイドを用意しています。

• LCP問題の特定と改善手順：DevTools、WebPageTest、CoreDashを使って、どのフェーズが遅いかを特定します。
• Chrome DevToolsによるLCPの診断：Performanceトレース内のLCPマーカーを確認します。
• LCP画像の最適化：フォーマット、サイズ、srcsetの活用方法。
• Resource Load Delay：LCP画像を早期にリクエストさせる方法。
• Resource Load Duration：ダウンロード処理自体の短縮。
• Element Render Delay：画像データ受信後、描画されるまでの遅延解消。