LCPとは？原因と改善方法を解説

SEO

LCP（Largest Contentful Paint）とは、ページを開いたときに、最初の表示範囲内にある最も大きな画像やテキストなどが表示されるまでの時間を測る指標です。

Core Web Vitalsの1つで、ページの「主要な内容がどれくらい早く見えたか」を判断するために使われます。LCPが遅い場合は、画像だけでなく、サーバー応答、CSS・JavaScript、Webフォント、キャッシュなど複数の原因を順番に確認する必要があります。

30秒でわかる結論

  • LCPはページの主要コンテンツが表示される速さを測るCore Web Vitalsの指標
  • 良好の目安は2.5秒以下
  • 評価ではモバイル・デスクトップごとに75パーセンタイルを見る
  • 2.5秒超～4.0秒以下は「改善が必要」、4.0秒超は「不良」の目安
  • LCP要素は大きな画像・テキストブロック・動画などになる
  • 画像を軽くするだけで必ずLCPが改善するとは限らない
  • TTFB、LCPリソースの発見遅延、読込時間、描画遅延に分けると原因を探しやすい
  • LCP画像へloading=”lazy”を付けるのは避ける
  • PageSpeed Insightsでは、可能なら実ユーザーデータを優先して判断する

LCPとは？

LCPは「Largest Contentful Paint」の略で、読み方は「ラージェスト・コンテントフル・ペイント」です。

web.devでは、ユーザーがページ読み込みを開始してから、最初のビューポート内にある最大の画像・テキストブロック・動画などが描画されるまでの時間として説明されています。

初心者向けに一言でいうと

LCPは、ページを開いて「主要な内容が見えた」と感じるまでの速さを見る指標です。

単にHTMLファイルの読み込みが終わるまでの時間ではありません。利用者が実際に見る大きなコンテンツの表示を基準にします。

LCPの良好な数値は何秒？

Googleとweb.devでは、良好なユーザー体験の目安としてLCP 2.5秒以下を推奨しています。

LCP 判定の目安
2.5秒以下 良好
2.5秒超～4.0秒以下 改善が必要
4.0秒超 不良

判定するときは、1回の計測だけを見るのではなく、ページ読み込みの75パーセンタイルをモバイルとデスクトップに分けて確認します。

75パーセンタイルの考え方

100回のページ訪問があった場合、速い順に75回目の値が2.5秒以内なら、多くのユーザーに対して良好なLCPを提供できていると考えます。

LCPになる要素

LCP候補になるのは、ビューポート内で大きく表示されるコンテンツです。

  • <img>画像
  • SVG内の<image>
  • 動画のポスター画像または最初のフレーム
  • CSSのurl()で読み込まれる背景画像
  • テキストを含むブロックレベル要素

WordPressでLCPになりやすい例

  • トップページのメインビジュアル
  • 記事上部の大きなアイキャッチ画像
  • ファーストビューの大きな見出し
  • ヒーローセクションの背景画像

ページによってLCP要素は異なります。「画像サイトだから必ず画像」「ブログだから必ず見出し」とは限りません。

LCPとFCPの違い

LCPと混同しやすい指標にFCP（First Contentful Paint）があります。

項目 LCP FCP
見るもの 主要な大きなコンテンツ 最初に表示されたコンテンツ
意味 メイン内容が見える速さ 何かが表示され始める速さ
例 大きなアイキャッチ ロゴ・背景・小さな文字など

最初にロゴだけ表示されても、メイン画像が何秒も出なければLCPは遅くなる可能性があります。

LCPが遅くなる4つの原因

LCPは、単純に「画像の容量」だけで決まりません。web.devではLCPを次の4つの時間へ分解して分析する方法を案内しています。

項目 意味
TTFB HTMLの最初の1バイトを受け取るまで
Resource load delay LCPリソースの読込開始までの遅れ
Resource load duration LCPリソース自体の読込時間
Element render delay 読込完了後、画面へ描画されるまでの遅れ

LCP ＝ TTFB ＋ リソース読込開始の遅延 ＋ リソース読込時間 ＋ 描画遅延

どこが長いかによって改善方法が変わります。

原因1．TTFBが遅い

TTFBが遅いと、HTMLの受信自体が遅れるため、その後に読み込むLCP画像やCSSの開始も遅れます。

TTFBが遅くなる代表例は次のとおりです。

  • WordPressのPHP処理が重い
  • データベース処理が遅い
  • ページキャッシュが使われていない
  • サーバーが混雑している
  • 複数回のリダイレクトがある
  • 利用者とサーバーの距離が遠い

改善方法

  • ページキャッシュを確認する
  • 重いプラグインやテーマ処理を見直す
  • データベース処理を確認する
  • 不要なリダイレクトを減らす
  • 必要ならCDNを検討する
  • サーバー負荷が高いならプランや環境を見直す

原因2．LCP画像の読み込み開始が遅い

画像自体が軽くても、ブラウザが「この画像が必要」と気付くのが遅ければLCPは改善しません。

特に次のケースでは、LCP画像の発見が遅れることがあります。

  • JavaScriptで後から画像を追加している
  • 画像URLがdata-srcなどへ隠されている
  • CSS背景画像として読み込んでいる
  • LCP画像を遅延読み込みしている

LCP画像をlazy-loadしない

web.devは、LCP画像へ遅延読み込みを設定しないよう案内しています。ファーストビューにある主要画像を遅らせると、LCPリソースの読み込み開始が遅れるためです。

WordPressでは画像へ自動的にloading属性が付与されることがありますが、LCP候補となるファーストビュー画像が適切に扱われているか確認します。

原因3．LCP画像そのものが重い

LCP要素が大きな画像なら、ファイル容量が大きいほどダウンロード時間が伸びやすくなります。

よくある状態

表示幅1200pxのヒーロー画像に、横5000px・3MBのJPEGをそのまま使用している。

改善方法

  • 表示サイズに合わせて画像寸法を縮小する
  • JPEG・PNGからWebP・AVIFを検討する
  • 画質を保ちながら圧縮する
  • srcset・sizesで適切な画像サイズを配信する
  • 不要に巨大な画像をファーストビューへ置かない

圧縮だけで改善しない場合もある

画像ダウンロードが速くなっても、JavaScriptの処理待ちなどで描画が止まっている場合、LCP全体がほとんど改善しないことがあります。

原因4．CSS・JavaScriptで描画が遅れている

LCP画像を読み込み終えていても、CSSやJavaScriptの処理が終わるまで画面へ表示できなければLCPは遅くなります。

web.devでは、描画遅延の代表原因として次を挙げています。

  • 大きなレンダリングブロックCSS
  • 同期JavaScript
  • JavaScriptでLCP要素を後からDOMへ追加
  • A/Bテストなどで要素を一時的に隠す
  • 長いメインスレッド処理

改善方法

  • 不要なCSSを減らす
  • 重要ではないJavaScriptの実行を遅らせる
  • ファーストビュー要素を初期HTMLで見つけやすくする
  • 重いJavaScript処理を減らす

fetchpriority=”high”は使うべき？

LCP候補の画像では、ブラウザへ優先度を伝えるためにfetchpriority=”high”が役立つ場合があります。

例

<img src=”/hero.webp” fetchpriority=”high” alt=””>

ただし、ページ内の多数の画像へhighを付けると、どれが本当に重要なのか分からなくなります。

highを乱用しない

web.devでは、LCPになりそうな画像に利用することを勧めていますが、多数の画像へ高優先度を設定することは推奨していません。

LCP画像をpreloadすべき？

LCP画像がCSS背景画像などで、初期HTMLからブラウザがすぐ発見できない場合は、preloadが役立つことがあります。

考え方

通常の<img>で初期HTMLからすぐ見つかる → 必ずしもpreload不要

CSS背景画像で発見が遅い → preloadを検討

preloadも増やしすぎると他の重要リソースと競合します。計測して必要なリソースだけに使います。

WebフォントがLCPを遅くする場合

LCP要素が大きなテキストブロックの場合、Webフォントの読み込みがLCPへ影響する場合があります。

フォントファイルの取得が遅い、CSSから発見されるまで時間がかかる、フォント表示設定によりテキスト描画が待たされる、といった原因があります。

確認すること

  • 不要なフォントウェイトを読み込んでいないか
  • 外部フォントが多数ないか
  • ファーストビューのフォント取得が遅くないか
  • 必要に応じてpreloadやfont-displayを検討する

PageSpeed InsightsでLCPを確認する方法

初心者がLCPを確認するならPageSpeed Insightsが分かりやすい方法です。

1．PageSpeed InsightsへURLを入力
2．モバイル・デスクトップを確認
3．実際のユーザー環境データを見る
CrUXデータがある場合は優先して確認します。
4．LCP要素を確認
5．診断で原因候補を確認
6．改善後に再計測

web.devでは、CrUXなどの実ユーザーデータが利用できる場合、Lighthouseのラボデータだけでなく、実際の利用者の数値を優先して状況を判断するよう案内しています。

実ユーザーデータとラボデータの違い

項目 実ユーザーデータ ラボデータ
代表例 CrUX Lighthouse
対象 実際の利用者 決められたテスト環境
用途 実際の問題把握 原因調査・改善テスト
数値 回線・端末差を含む 再現しやすい

両方に役割があります。実ユーザーデータで問題を確認し、ラボデータで原因を調査する流れが分かりやすいです。

WordPressでLCPを改善する順番

初心者向け改善順序

  1. PageSpeed InsightsでLCP要素を特定する
  2. TTFBが極端に遅くないか確認する
  3. LCP画像へlazy-loadが付いていないか確認する
  4. LCP画像の容量・寸法を最適化する
  5. キャッシュを確認する
  6. 重いCSS・JavaScriptを確認する
  7. 必要ならfetchpriorityやpreloadを検討する
  8. 改善後に実ユーザーデータを再確認する

最初からプラグインを増やさない

「高速化プラグインを入れれば直る」と決めつけず、まずLCP要素と遅れている区間を特定してください。原因がサーバー応答なら画像プラグインだけでは解決しません。

LCP改善とレンタルサーバーの関係

レンタルサーバーは主にTTFBやWordPressの処理速度へ影響します。

ただし、LCPが遅い原因が3MBの画像や重いJavaScriptなら、サーバーを変えただけでは十分な改善にならないことがあります。

TTFBが遅い

サーバー影響：大きい

キャッシュ、PHP、DB、混雑状況などを確認します。

LCP画像が重い

サーバー影響：中

まず画像サイズ・形式・配信方法を確認します。

JavaScript描画待ち

サーバー影響：小～中

テーマ・プラグイン・フロントエンド処理を確認します。

CSS背景画像の発見遅れ

サーバー影響：小

リソース発見・優先度を見直します。

LCPを改善すればSEO順位は上がる？

「LCPを2.5秒以下にすれば順位が必ず上がる」とは言えません。

GoogleはCore Web Vitalsを、ページ体験を評価する複数の要素の一部として扱っています。またGoogleは、Core Web Vitalsの1つや2つだけに集中するのではなく、ページ全体として良い体験を提供するよう案内しています。

LCP改善の主目的

検索順位だけを目的にするのではなく、ユーザーが主要コンテンツを早く見られる状態を作ることを優先してください。

よくある改善ミス

次の改善は要注意

  • LCP画像へloading=”lazy”を付ける
  • すべての画像へfetchpriority=”high”を付ける
  • 画像だけ圧縮して原因調査を終える
  • PageSpeed Insightsを1回測った値だけで判断する
  • キャッシュプラグインを複数重ねる
  • スコア100点だけを目的に表示や機能を壊す

教科書判定

教科書判定

LCPが遅いときは「画像圧縮」ではなく、まずLCP要素と遅延区間を特定する

初心者はまずPageSpeed InsightsでLCP要素を確認し、2.5秒以下を目安にしてください。

LCP要素が画像なら、lazy-loadの有無、ファイル容量、画像寸法、読込開始のタイミングを確認します。TTFBが遅いなら、画像より先にサーバー処理・キャッシュ・PHP・データベースを確認します。

WordPressでは高速化プラグインを闇雲に追加せず、「TTFB」「読込開始の遅れ」「リソース読込」「描画遅延」のどこが長いかを切り分けるのが最も効率的です。

FAQ

Q. LCPは何秒なら良好ですか？

A. Googleとweb.devでは2.5秒以下を良好の目安としています。モバイル・デスクトップごとに、ページ読み込みの75パーセンタイルで評価します。

Q. LCPが4秒なら遅いですか？

A. 4.0秒までは「改善が必要」、4.0秒を超えると「不良」の目安です。まずLCP要素と遅延原因を確認してください。

Q. LCP画像はlazy-loadしてよいですか？

A. 基本的には避けます。LCP候補のファーストビュー画像を遅延読み込みすると、リソースの取得開始が遅れ、LCPを悪化させる可能性があります。

Q. サーバーを高速化すればLCPは改善しますか？

A. TTFBが原因なら改善する可能性があります。ただし画像容量やJavaScriptの描画待ちが原因なら、サーバーだけ変えても十分に改善しない場合があります。

Q. PageSpeed InsightsのLCPが毎回違うのはなぜですか？

A. ネットワーク、端末、キャッシュ、サーバー負荷などで数値は変わります。1回のラボ測定だけで判断せず、CrUXなど実ユーザーデータも確認してください。

まとめ

LCP改善は「最大要素を早く表示するまでの流れ」を分解して考える

  • LCPはCore Web Vitalsの読み込み性能指標
  • 良好の目安は2.5秒以下
  • 75パーセンタイルで評価する
  • LCP要素は画像・テキスト・動画など
  • TTFBが遅いならサーバー・キャッシュを確認する
  • LCP画像の発見・読込開始を遅らせない
  • LCP画像へlazy-loadを使わない
  • 画像容量と寸法を最適化する
  • CSS・JavaScriptによる描画遅延も確認する
  • 実ユーザーデータとラボデータを使い分ける

次に読む

次に読む

「Core Web Vitalsとは？SEOとの関係を初心者向けに解説」「INPとは？原因と改善方法を解説」「CLSとは？原因と改善方法を解説」「TTFBとは？サーバー応答速度の見方と改善方法」もあわせて確認してください。