LCP を改善する — 最大コンテンツの描画

LCP（Largest Contentful Paint）は、ビューポート内で最も大きなコンテンツ要素が描画されるまでの時間を測る Core Web Vitals の指標です。実ユーザーの 75 パーセンタイルで 2.5 秒以下が良好とされます。多くは主要な画像や大きな見出しが対象で、サーバー応答・レンダリングブロック・画像の読み込み優先度が主なボトルネックになります。

執筆: JIT株式会社公開: 2026年7月17日

LCP とは何ですか？

LCP は、ページを開いてから、画面内で最も大きなコンテンツ要素が表示されるまでの時間を測る指標です。多くの場合は主要な画像や大きな見出し、動画のポスター画像が対象になります。ページ全体の読み込み完了ではなく「主役が見えた瞬間」を測るため、利用者の体感に近い速度指標として Core Web Vitals に採用されています。

LCP という名前は Largest Contentful Paint（最大コンテンツの描画）の頭文字です。ここで大事なのは、測っているのが「ページ全体が読み終わったか」ではなく「主役が見えたか」だという点です。利用者は解析タグやフッターの読み込みが終わったかどうかには関心がなく、開いたページの中心にある画像や見出しが見えれば「表示された」と感じます。LCP はその体感を、機械的に測れる 1 つの時刻として切り出したものです。

そのため、load イベントや DOMContentLoaded が速くても LCP は遅い、という食い違いが普通に起こります。 HTML の受信は一瞬でも、肝心の主要画像が後回しにされていれば、利用者にとっての表示は遅いままです。 LCP は Core Web Vitals を構成する 3 指標の 1 つで、表示の速さを担当します。

良好とされる基準は何秒ですか？

良好は 2.5 秒以下、要改善は 2.5〜4 秒、不良は 4 秒超が基準です。判定は平均ではなく、実際の訪問者の 75 パーセンタイル値で行われます。つまり訪問者の 4 分の 3 が 2.5 秒以内に主要コンテンツを見られて、はじめて良好と評価されます。高速な端末の利用者だけを見て満足しないための設計です。

LCP の評価基準（実ユーザーの 75 パーセンタイル値で判定）
評価	LCP の値	意味
良好	`2.5 秒以下`	主要コンテンツが十分速く表示されている
要改善	`2.5〜4 秒`	遅いと感じる利用者が一定数いる
不良	`4 秒超`	多くの利用者が待たされている

注意したいのは、これらが平均値ではなく 75 パーセンタイル値で判定されることです。平均だと、高速な端末や光回線の利用者が多いだけで数値が良く見え、低速回線のユーザーが待たされている実態を覆い隠せてしまいます。 75 パーセンタイルなら、訪問者の 4 分の 3 が 2.5 秒以内に主要コンテンツを見られて初めて良好になり、ごまかしが効きません。

何が LCP 要素になりますか？

ビューポート（最初に見える画面）の中で、最も大きく描画されたコンテンツ要素が LCP 要素です。具体的には大きな画像、背景画像、動画のポスター、そしてまとまったテキストブロックや大きな見出しが候補になります。画面外の要素やスクロールしないと見えない要素は対象外で、読み込みの途中で LCP 要素が入れ替わることもあります。

「最も大きなコンテンツ要素」は、面積で決まります。ヒーロー画像のような分かりやすいものだけでなく、テキストが主体のページでは大きな見出しや本文のかたまりが LCP 要素になることもあります。 LCP 要素の候補になるのは、主に次のものです。

画像 — <img> や <svg> 内の <image>、CSS の background-image
動画 — <video> のポスター画像（先頭フレーム）
テキストブロック — 見出しや段落など、まとまったブロックレベルのテキスト

読み込みの途中で LCP 要素が入れ替わる点も知っておく価値があります。最初は見出しが最大でも、後から大きな画像が表示されれば、そちらが LCP 要素として記録し直されます。だからこそ、ファーストビューで最も目立つ画像を最優先で表示させることが、そのまま LCP の改善に直結します。

LCP が遅くなる主な原因は何ですか？

主な原因は 4 つです。サーバー応答（TTFB）が遅い、CSS や JavaScript がレンダリングを妨げている、LCP 画像の読み込みが遅い、本文をクライアント側の JavaScript で描画している、のいずれかです。多くの場合は複数が重なっています。どの区間が長いかを先に特定してから対策しないと、当てずっぽうでは数値が動きません。

LCP が遅くなる主な原因と、効く対策
原因	何が起きているか	効く対策
サーバー応答（TTFB）が遅い	最初の 1 バイトが返るまで時間がかかる	キャッシュ・CDN・DB クエリやサーバー処理の高速化
レンダリングブロック	CSS/JS の読み込みが描画をせき止める	クリティカル CSS の分離・JS の非同期化（defer）
LCP 画像の読み込みが遅い	画像の発見や取得が後回しになる	preload・`fetchpriority="high"`・lazy を外す・画像最適化
クライアント描画（CSR）	本文を JS で組み立ててから描画する	サーバー側レンダリング（SSR）・静的生成へ寄せる

実務では、これらが単独ではなく重なって効いていることがほとんどです。たとえば TTFB が 1.5 秒ある状態では、画像をいくら軽くしても LCP が 2.5 秒を切ることは原理的にありません。先にどの区間が長いかを特定し、一番長い区間から順に潰すのが正攻法です。区間ごとの詳しい分解はCore Web Vitals の解説にまとめています。

LCP を改善するには何をすればよいですか？

最も効くのは、主要画像から lazy を外して fetchpriority=high を付け、必要なら preload で先読みさせることです。あわせて、サーバー応答を CDN やキャッシュで速くし、レンダリングを妨げる CSS/JS を減らします。本文を JavaScript で描画しているサイトは、サーバー側でレンダリング（SSR）する方向へ寄せると LCP が安定します。

最も費用対効果が高いのは、ファーストビューの主要画像の扱いを正すことです。「全画像に loading="lazy" を付ける」という一括設定が、LCP 画像にまで適用されて放置されている例を頻繁に見かけます。 lazy は画面外の画像にだけ付けるもので、最初に見える画像に付けると LCP を確実に悪化させます。

主要画像の正しい書き方

<!-- ❌ 主要画像に lazy。ブラウザは「後で読む画像」と判断し、発見も取得も後回しにする -->
<img src="/hero.webp" loading="lazy" alt="製品の外観">

<!-- ✅ 最初の画面に映る画像は lazy を付けず、優先度を上げる。
     width/height でレイアウトの場所を先に予約する（CLS 対策も兼ねる） -->
<img src="/hero.webp" width="1200" height="630"
     fetchpriority="high" decoding="async" alt="製品の外観">

<!-- ✅ Next.js の Image なら priority を付けるだけで
     fetchpriority=high と preload が自動で入る -->
<Image src="/hero.webp" width={1200} height={630} priority alt="製品の外観" />

次に効くのが「発見の早さ」です。LCP 画像を CSS の背景や JavaScript から読み込んでいると、ブラウザは HTML を先読みしただけでは画像の存在に気づけず、取得が数百ミリ秒遅れます。<link rel="preload"> で予告し、あわせてレンダリングを妨げる CSS/JS を減らします。

発見を早める / レンダリングブロックを減らす

<!-- LCP 画像を CSS の background-image や JS 経由で読み込んでいると、
     ブラウザのプリロードスキャナが HTML だけでは発見できず、取得が数百 ms 遅れる。
     明示的に予告して埋め合わせる -->
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">

<!-- レンダリングを妨げる CSS/JS を減らす: 重要な CSS だけ先に読み、残りは遅延させる -->
<link rel="stylesheet" href="/critical.css">
<script src="/app.js" defer></script>

そしてサーバー応答（TTFB）です。ここが遅ければ他の対策の効果は頭打ちになります。キャッシュ・CDN・サーバー処理の見直しで、最初の 1 バイトが返るまでを短くします。本ツールは TTFB・転送量・圧縮・キャッシュ設定・リダイレクト連鎖を JavaScript 実行なしで実測するため、サーバー側が足を引っ張っているかどうかは、その場で判定できます。

本文をクライアント側の JavaScript で描画しているサイトは、描画開始そのものが遅れるため LCP が構造的に不利になります。サーバー側でレンダリング（SSR）や静的生成へ寄せると改善しますが、これはAI クローラーに本文が届くかどうかという別の重要問題とも直結します。詳しくは JavaScript なしで本文が読めないと、AI に引用されないを参照してください。

実測（CrUX）とシミュレーション（Lighthouse）は何が違いますか？

検索の評価に使われるのは、実ユーザーの計測値である CrUX（フィールドデータ）だけです。Lighthouse や PageSpeed Insights のラボ値は 1 台・1 回のシミュレーションで、原因の特定には向きますが合否そのものではありません。「Lighthouse は速いのに Search Console では不合格」は矛盾ではなく、測っているものが違うために起きる正常な現象です。

LCP の数値には 2 つの出どころがあり、これを混同すると改善の努力が空回りします。検索の評価に使われるのは、実ユーザーの環境で集めた CrUX（フィールドデータ）だけです。一方 Lighthouse や PageSpeed Insights のラボスコアは、低速回線・低速 CPU を想定した1 台・1 回のシミュレーションで、原因を特定するためのデバッガとして使うものです。

そのため「Lighthouse は 90 点なのに Search Console では LCP 不合格」という状態は矛盾ではありません。ラボ値は合否ではなく手がかりであり、実ユーザーの回線やキャッシュ状況を再現していないからです。合否は CrUX で見て、原因は Lighthouse で追う——この役割分担を守ることが、遠回りを避ける近道です。なお CrUX は過去 28 日間の集計のため、改善が反映されるまで時間がかかる点にも注意してください。

自分のサイトの LCP をどう確認すればよいですか？

実ユーザーの LCP は Google Search Console の「ウェブに関する主な指標」レポートか、PageSpeed Insights 上部のフィールドデータで確認します。原因の特定には Lighthouse や Chrome DevTools の Performance パネルが向いており、どの要素が LCP 要素で、どの区間が長いかを分解できます。まず実測で合否を見て、次にラボで原因を追う順が効率的です。

確認は「実測 → 原因追跡」の順が効率的です。まず実ユーザーの LCP が良好かどうかを Google Search Console の「ウェブに関する主な指標」や PageSpeed Insights のフィールドデータで確認します。不合格なら、Lighthouse や Chrome DevTools の Performance パネルでどの要素が LCP 要素か、そしてその要素のどの区間が長いかを分解します。

機械で分かるのは数値と区間までです。「その画像を本当にファーストビューに置くべきか」のような設計判断は、最終的に人が下します。まずは主要画像の lazy を外し、preload と優先度を整え、サーバー応答を詰める——この 3 点だけでも、多くのサイトで LCP は目に見えて改善します。セットで見直したい画像そのものの軽量化は画像最適化にまとめています。