LCP(Largest Contentful Paint)を改善するには、遅れている場所を先に特定し、その場所に合う対策だけを打ちます。LCPとは、ビューポート内で最も大きな画像やテキストブロックが表示されるまでの時間を測る指標です。Googleは2.5秒以下を「良好」、4.0秒超を「不良」としています。
この記事で扱う内容は次の3点です。
- LCPの時間を4つの区間に分け、どこで遅れているかを見つける方法
- 区間ごとの原因と対策(一覧表つき)
- 修正の前後を同じ条件で測り、数値で残す手順
Mobilisticaは自社トップページのLCPが5.76秒から3.22秒へ縮んだ計測記録を公開しています。ここではその進め方を、ほかのページにも使える手順として整理しました。
LCPとは?合格ラインと測り方
LCPはCore Web Vitalsを構成する3指標のひとつで、読み込みの速さを表します。web.devのLCP解説は、2.5秒以下を「良好」、4.0秒超を「不良」、その間を「改善が必要」と区分しています。
判定に使われるのは平均値ではなく、訪問の分布です。同じ解説は、モバイルとデスクトップのそれぞれでページ読み込みの75パーセンタイルを測るよう勧めています。つまり、訪問の75%以上が2.5秒以下に収まっている状態が目標です。
測るときはPageSpeed InsightsにページのURLを入力します。結果画面には、どのHTML要素がLCPと判定されたかが表示されます。対象がヒーロー画像なのか、見出しのテキストなのかで打つ手が変わるため、まずここを確認してください。
LCPを4つの区間に分けて遅い場所を見つける
LCPの秒数だけを見ても、直す場所は決まりません。web.devの最適化ガイドは、LCPの合計時間を4つのサブパートに分けて考える方法を示しています。
| 区間 | 何の時間か | 最適化されたページでの目安 |
|---|---|---|
| Time to First Byte(TTFB) | 読み込み開始から、HTMLの最初のバイトが届くまで | 約40% |
| リソース読み込みの遅延 | TTFBから、LCPの画像やフォントの読み込みが始まるまで | 10%未満 |
| リソースの読み込み時間 | LCPの画像やフォントそのもののダウンロード | 約40% |
| 要素のレンダリングの遅延 | 読み込み完了から、画面に描かれるまで | 10%未満 |
表の割合は同ガイドが「ガイドラインであり、厳格なルールではありません」と断っている目安です。割合を秒数に換算して目標にする使い方も、ガイド自身が勧めていません。見るべきなのは、名前に「遅延」と付く2区間が膨らんでいないかどうかです。
なぜなら、この2区間は待ち時間であって、通信そのものにかかる時間ではないからです。ガイドは2つの遅延を「できるだけゼロに近づける」よう求めています。ここが大きいページは、設定の見直しだけで縮む余地を残しています。
LCP改善の手順(4ステップ)
作業は次の順で進めます。途中を飛ばすと、効いた施策と効かなかった施策の区別がつかなくなります。

-
ステップ1:PageSpeed InsightsでLCP要素を特定する
診断結果に表示されるLCP要素が、改善の対象です。画像タグか、テキストブロックかをここで確定させます。
-
ステップ2:4区間のどこが長いかを見る
TTFB・読み込みの遅延・読み込み時間・レンダリングの遅延のうち、目安から外れている区間を1つ選びます。複数が外れているときは、遅延の2区間から先に手を付けます。
-
ステップ3:その区間の対策を1つだけ入れる
次章の一覧表から、選んだ区間に対応する施策を1つ適用します。同時に複数を変えると、どれが効いたのかを後から切り分けられません。
-
ステップ4:同条件で再計測し、Before/Afterを記録する
モバイルならモバイル、PCならPCと条件をそろえて測り直します。スコアとLCPの秒数を並べて残しておくと、次に直す場所を決める材料になります。
Mobilisticaの自社トップページでは、Google Fontsの読み込み方を変える修正でLCPが5.76秒から3.22秒になりました。計測条件と修正内容は自作の無料診断ツールで自サイトを測ったらLCPが5秒超だった話に記録しています。
原因別の対策一覧表
よくある原因を、どの区間に効く対策かとあわせて並べました。対策の中身はweb.devの最適化ガイドが挙げている内容に沿っています。
| 原因 | 該当する区間 | 主な対策 |
|---|---|---|
LCP画像にloading="lazy"が付いている |
リソース読み込みの遅延 | LCP画像を遅延読み込みの対象から外す |
| LCP画像がCSSの背景画像やJavaScript経由で読み込まれる | リソース読み込みの遅延 | HTMLから見つけられる形にするか、<link rel="preload">で先読みする |
| LCP画像の読み込み優先度が低い | リソース読み込みの遅延 | LCPになる<img>にfetchpriority="high"を付ける |
| 画像ファイルが重い | リソースの読み込み時間 | 表示サイズに合わせた縮小、WebPなどへの変換、キャッシュの設定 |
| Webフォントの読み込み待ちでテキストが出ない | リソースの読み込み時間 | font-displayをauto・block以外にする、フォントを軽くする |
| CSSやJavaScriptが描画を止めている | 要素のレンダリングの遅延 | 使っていないCSSとスクリプトの削除、defer・asyncの指定 |
| サーバーの応答が遅い、リダイレクトが多い | TTFB | キャッシュとCDNの導入、リダイレクト回数の削減 |
遅延読み込みについて、同ガイドは「LCP 画像を遅延読み込みしないでください」と警告しています。fetchpriority="high"にも注意書きがあります。複数の画像に高い優先度を付けると、指定の効果が薄れるという内容です。対象はLCPになる1枚に絞ってください。
TTFBは後続のすべての区間に響きます。ガイドは遅くなる例として、複数回のリダイレクトと、CDNのキャッシュを使えない配信を挙げています。
つまずきやすいポイント・注意点
1つ目の落とし穴は、ラボデータとフィールドデータの混同です。PageSpeed Insightsの診断欄に出る数値は、決まった条件で1回測ったラボデータです。一方、訪問者の端末から集まった値はフィールドデータ(CrUX)と呼ばれます。
「LCP は、ビューポート内に表示される最大の画像、テキスト ブロック、または動画のレンダリング時間を、ユーザーが最初にページに移動したタイミングと比較する形で確認できます。」(web.devのLCP解説より)
※このページは、接続の準備やリダイレクトにかかる時間もLCPに含まれると説明しています。こうした時間は訪問者の環境で大きくなりやすく、ラボとフィールドで数値が食い違う一因です。Google検索セントラルも、Core Web Vitalsを「実際のユーザー エクスペリエンスを測定する一連の指標」と説明しています。
2つ目は、計測値のばらつきです。Lighthouseのスコアリング解説は変動の要因として、配信される広告の変更、通信経路の変化、ブラウザ拡張機能などを挙げています。1回の結果で判断せず、同じ条件で複数回測ってから比べてください。
3つ目は、LCPだけを見て終わることです。フォントや画像の読み込み方を変えると、表示のずれ(CLS)に影響が出る場合があります。修正のあとはCLSとINPの数値も同じ画面で確かめておくと安心です。
よくある質問(LCP FAQ)
LCPはどれくらいの数値を目指せばいいですか?
目標は2.5秒以下です。web.devは、ページ読み込みの75%以上でこの値に収めることを勧めています。4.0秒を超えている場合は、まず4.0秒以下、次に2.5秒以下と段階を分けると進めやすくなります。
LCPを改善すると検索順位は上がりますか?
Google検索セントラルは、Core Web Vitalsをコアランキングシステムが考慮する要素のひとつと説明しています。ただし数ある要素の一部であり、LCPの改善だけで順位が上がるとは案内されていません。内容の充実と並行して進めてください。
計測するたびに数値が変わるのはなぜですか?
ラボデータは、測ったときの通信経路や配信される広告、ブラウザ拡張機能などの影響を受けます。Lighthouseの公式解説も、こうした状況の変化を変動の主な原因に挙げています。複数回測るか、フィールドデータとあわせて見てください。
画像を圧縮すればLCPは十分に速くなりますか?
効くのは、LCP要素が画像で、しかも読み込み時間の区間が長い場合です。遅延読み込みの指定やサーバーの応答が原因なら、圧縮しても数値はほとんど動きません。先に4区間のどこが長いかを確認してください。
まとめ
要点は次の3つです。
- LCPを4つの区間に分け、目安から外れている区間を1つ選ぶ
- その区間に対応する対策を1つずつ入れ、毎回同じ条件で測り直す
- ラボデータに加えて、フィールドデータ(CrUX)でも確かめる
Mobilisticaは自社サイトの計測記録を公開しながら、改善の過程を今後も共有していきます。自分のサイトのLCPをすぐ確認したい方は、モバイルECサイト無料診断をお使いください。改善の全体像から押さえたい方には、表示速度改善の進め方:効果が大きい施策から着手する方法が向いています。
※本記事の自社計測値はPageSpeed Insightsによる計測時点のもので、測定環境やタイミングにより変動します。
※本記事は一般的な情報提供を目的としたものです。改善の効果はサイトの構成によって異なるため、ご自身のサイトで再計測のうえご判断ください。
最終更新: 2026年10月6日
Mobilisticaの運営者情報はこちらをご覧ください。
[…] 切り分けにはFCPとLCPの差が使えます。差が小さいときの容疑者は、サーバー応答やレンダリングを止めている読み込みなど、描画の入口です。差が大きいときは主要な画像やフォントの取得を疑います。LCPが速いのにTBTだけ大きい場合は、JavaScriptの実行時間が本命です。個別の直し方はLCP改善の手順とINP改善の手順に分けて書いています。 […]
[…] 4サイトともTBTは50ミリ秒以下で、Lighthouseのスコア上は「良好」と判定される水準です。一方でLCP改善の手順:原因の特定から実践までで扱った基準に照らすと、erii-waso.comとtabi-no-tetsuzuki.comのLCPは7秒台で「不良」の水準にあります。同じサイトでもLCPとTBT(INPの代理指標)の良し悪しは一致しない、という点は実測からも確認できました。ただし繰り返しになりますが、TBTはあくまでラボの代理指標であり、実際のINPを保証する数値ではありません。 […]
[…] 4サイトともCLSは0.1の基準を大きく下回り、良好な水準でした。一方でtabi-no-tetsuzuki.comとerii-waso.comのLCPは7秒台です。LCP改善の手順:原因の特定から実践までで扱った基準に照らすと「不良」の水準にあります。同じサイトでもCLSとLCPの良し悪しは一致しない、という点が実測から確認できました。CLSが最初から良好になりやすいのは、後述するとおり画像サイズの指定など基本的な作りを守っているだけで悪化を避けられる指標だからです。 […]
[…] LCP改善の手順:原因の特定から実践まで【自社実測データ付き】 – Mobilistic… より: 2026年10月6日 5:57 PM […]