改善事例

LCP改善の手順:原因の特定から実践まで【自社実測データ付き】

PageSpeed Insightsで自分のサイトを測ったところ、「LCPの要素: 5.8秒」という赤い警告だけが残った――そこから先に何を直せばいいか分からなくなった。そんな相談がMobilisticaにはよく届きます。LCP(Largest Contentful Paint)とは、ページ内で最も大きな要素の描画が完了するまでの時間を示す指標です。Googleの基準では2.5秒以内が「良好」、4.0秒を超えると「不良」と判定されます。

この記事でわかることは次の3点です。

  • LCPが遅くなる原因を画像・フォント・JS・サーバーの4系統に切り分ける方法
  • 原因別の対策と、優先度の目安(一覧表つき)
  • 修正前後をBefore/Afterで実測データとして残す手順

Mobilisticaでは自社サイトのLCPが5.76秒だった状態から3.22秒まで縮んだ実測記録を公開しており、今回はその手順を一般化して整理しました。実際にPageSpeed Insightsで診断した人向けに、公開時点の情報をもとに書いています。

LCPとは?合格ラインと診断にかかる時間

LCPは、ページ内で最も大きな画像またはテキストブロックが描画されるまでの時間を測るCore Web Vitalsの指標のひとつです。web.devの公式解説では、2.5秒以内を「良好」、2.5〜4.0秒を「要改善」、4.0秒超を「不良」の3段階で定義しています。

診断自体はPageSpeed Insightsに自分のサイトのURLを入力するだけで、数十秒ほどで完了する手軽さです。診断結果の「診断」タブを開くと、どの要素がLCPと判定されているか(見出しの画像なのか、ヒーローテキストなのか)を具体的に確認できます。原因を推測で決めつけずに、まずこの画面で「何が遅いのか」を特定するところから始めるのが遠回りのようで一番早い進め方です。

なぜなら、LCPが遅い原因は画像・フォント・JavaScript・サーバー応答のどれか1つに集中していることが多いからです。原因を絞らずに高速化テクニックを片っ端から試すと、効果のない変更に時間を取られてしまいます。

LCP改善の手順(4ステップ)

実際にLCPを改善する人が踏む流れは、おおむね次の4ステップに集約されます。1ステップあたり数分から数十分程度で進められます。

診断・原因切り分け・対策・再計測の4ステップをイメージした図
診断→原因の切り分け→対策→再計測、という4ステップの流れ
  1. ステップ1:PageSpeed InsightsでLCP要素を特定する

    診断結果の「LCPの要素」欄に表示されるHTML要素が、実際に遅延の対象です。画像タグなのか、見出しのテキストブロックなのかをまず確認します。

  2. ステップ2:原因を4系統に切り分ける

    「診断」タブの警告一覧を見て、大きな画像・Webフォント・レンダリングブロックするJavaScript・サーバー応答時間(TTFB)のどれが該当するかを絞り込みます。

  3. ステップ3:該当する対策を1つずつ実施する

    次章の一覧表から対策を選び、優先度の高いものから順に1つずつ適用します。同時に複数を変更すると、何が効いたのか分からなくなるため注意が必要です。

  4. ステップ4:同条件で再計測し、Before/Afterを記録する

    同じデバイス条件(モバイル/PC)で再計測し、スコアとLCP秒数の変化を記録します。改善が数字で残ると、次に何を直すかの優先順位も立てやすくなります。

Mobilisticaが自社サイトで実施した記録では、フォントの読み込み方式を1つ変更しただけで、トップページのLCPが5.76秒から3.22秒まで縮みました。詳しい手順は自作の無料診断ツールで自サイトを測ったらLCPが5秒超だった話にまとめています。

原因別の対策一覧表

LCPが遅くなる原因は、大きく5パターンに分類できます。実際にLCPの改善に取り組む人は、まず自分のケースがどれに当てはまるかをこの表で確認するとよいでしょう。

原因 具体的な症状 主な対策 優先度
大きな画像がLCP要素 ヒーロー画像やアイキャッチの表示に時間がかかる 画像圧縮・WebP変換・遅延読み込み対象からの除外
Webフォントがレンダリングをブロック 見出しや本文の描画がフォント読み込み待ちで止まる フォントの非同期読み込み・プリコネクト・サブセット化
JavaScriptが処理をブロック メインスレッドが専有され、LCP要素の描画が遅れる 不要スクリプトの削除・defer/async化
サーバー応答が遅い(TTFB) 最初のバイトが届くまでに時間がかかる キャッシュ導入・CDN・ホスティングの見直し
CSS/DOM構造が複雑 レイアウト計算が描画のボトルネックになる 不要なCSSの削減・DOM構造の簡素化

優先度は「該当するケースの多さ」と「個々の改善幅」を基準に並べています。詳細な実装方法はweb.devのLCP最適化ガイドにも具体的な手順が載っています。

つまずきやすいポイント・注意点

LCP改善で一番つまずきやすいのは、ラボデータとフィールドデータの違いを混同することです。PageSpeed Insightsの数値は「ラボデータ」と呼ばれる一回限りの測定値です。実際のユーザー環境の集計値である「フィールドデータ」(CrUX)とは、別の指標を見ています。

「LCPは、ページ内の最大の画像またはテキストブロックが描画されるまでの時間を報告する指標です。ユーザーがURLをリクエストした時点から計測が始まります」(web.dev「Largest Contentful Paint (LCP)」より)

※ラボデータは満点でも、実際のユーザーの回線・端末によってはフィールドデータが悪化しているケースもあります。Google検索セントラルのCore Web Vitalsガイドでは、検索順位の評価に使われるのはフィールドデータであると明記されています。

もう一つの落とし穴は、LCPだけを見てCLS(表示の安定性)やINP(応答性)の悪化に気づかないことです。一方で、3指標は独立して評価されるため、LCPを直した後は必ずCLS・INPも合わせて確認する必要があります。数値は測定のたびに数%前後変動するため、単発の計測結果だけで一喜一憂しないことも実務上は大切な心がけです。

よくある質問(LCP FAQ)

LCPはどれくらいの数値を目指せばいいですか?

Googleの基準では2.5秒以内が「良好」です。2.5〜4.0秒は「要改善」、4.0秒を超えると「不良」と判定されます。まずは4.0秒切り、次に2.5秒切りという2段階で目標を置くと進めやすくなります。

LCPを改善すると検索順位は上がりますか?

LCPはCore Web Vitalsの一部として、ページ体験に関するランキング要因の一つに含まれます。ただしGoogle自身が案内している通り、コンテンツの質を満たした上での土台という位置づけであり、単独で順位を大きく動かす要素ではありません。

計測するたびに数値が変わるのはなぜですか?

PageSpeed Insightsのラボデータは、その時のネットワーク状況やサーバー負荷の影響を受けるため、測定のたびに数%前後変動します。傾向を確認したいときは複数回計測するか、実ユーザーのフィールドデータ(CrUX)も合わせて見るのが確実です。

画像を圧縮すればLCPは十分に速くなりますか?

画像がLCP要素の場合は効果がありますが、原因がWebフォントやサーバー応答であれば画像だけ直しても数値は変わりません。まず診断結果でLCP要素が何かを確認してから対策を選ぶ順番が欠かせません。

まとめ

LCP改善で押さえておきたいポイントは次の3つです。

  • 原因を画像・フォント・JS・サーバーの4系統に切り分けてから対策する
  • 優先度の高いものから1つずつ直し、都度Before/Afterを再計測する
  • ラボデータだけでなく、フィールドデータ(CrUX)も合わせて確認する

Mobilisticaでは自社サイトの実測記録を公開しながら、こうした改善プロセスをこれからも共有していきます。今すぐ自分のサイトのLCPを確認したい方は、モバイルECサイト無料診断で診断してみてください。改善の全体像から先に押さえたい方は、表示速度改善の進め方:効果が大きい施策から着手する方法もあわせてご覧ください。


※本記事はPageSpeed Insightsによる公開時点の計測をもとに作成しており、測定値は測定環境やタイミングにより変動します。
※本記事は一般的な情報提供を目的としており、個人の見解を含む内容です。実際の改善効果はサイトの構成によって異なるため、ご自身のサイトでの再計測をおすすめします。
最終更新: 2026年7月26日
Mobilisticaの運営者情報はこちらをご覧ください。