LCPの改善方法｜Core Web Vitalsとの関係や測定ツールも解説

LCP（Largest Contentful Paint）は「ページの表示速度」「読み込み時間」を示すCore Web Vitalsの指標です。以下では測定方法、スコアが低下する原因、4つのサブパートによる診断、具体的な改善方法までを解説します。

LCPとは？

👉 このパートをまとめると！
LCPはページ表示速度の指標で、2.5秒以下が良好の基準です。

LCPは読み込み速度を示すCore Web Vitalsの中核指標で、実ユーザーの計測値で合否が判定されます。

LCPとはLargest Contentful Paintの略で、「ページの表示速度」や「読み込み時間」を示す指標です。

直訳すると「最大コンテンツの描画」となり、正確にはそのページにおける最もサイズの大きなコンテンツの読み込みにかかる時間が問題となります。SEOにおけるLCPの重要性を理解するためには、Core Web Vitalsを知らなければなりません。

Core Web Vitalsは2021年6月中旬以降に段階的に導入されたランキング要因の1つで、2026年8月時点でも引き続きGoogle検索のランキングシステムで使用されるページエクスペリエンスの指標です。構成要因は3つで、「INP（Interaction to Next Paint＝インタラクションから次のペイントまでの時間）」と「CLS（Cumulative Layout Shift＝累積レイアウトシフト）」、そしてLCPが含まれます。かつて使われていたFID（First Input Delay）は2024年3月12日にINPへ置き換えられ、2024年9月9日にサポートが終了しており、LCPは今後もユーザーファーストなコンテンツ作成に欠かせない視点です。

LCPの評価基準は下記の3段階に分かれます。2.5秒以下は「良好」、2.5秒を超えて4.0秒以下は「改善が必要」、4.0秒を超えると「不良」と判定されます（実ユーザーの計測値をもとにした判定方法は次の見出しで解説します）。

出典：Google Developers「Web Vitals の概要: サイトの健全性を示す重要指標」

LCPの合否は実ユーザーデータのp75（75パーセンタイル）で判定される

PageSpeed Insightsの1回の測定結果とGoogle Search Consoleの合否が一致しないのは、判定に使うデータが異なるためです。LCPの合否は、実際の訪問者の計測値（フィールドデータ）の75パーセンタイル（p75）で判定されます。web.devは「モバイル デバイスとデスクトップ デバイスでページ読み込みの75パーセンタイルを測定することをおすすめします」と説明しており、訪問の75%が満たしている値が基準値と比較されます。条件の良い回線で1回だけ測定して2.5秒以下が出ても、条件の悪い訪問が25%を超えていれば不合格です。

実際、当社サイト（gmotech.jp オリジン全体・モバイル）のフィールドデータ（2026年5月時点のCrUXデータ）では、LCPのp75は1.34秒で「良好」でした。オリジン単位の値のためWEB集客ラボ以外のページも含みますが、個別ページの1回の測定だけでなく、サイト全体のp75を継続確認することが実務では重要です。

出典：Largest Contentful Paint（LCP）・Web Vitals（web.dev）

LCPの測定方法

👉 このパートをまとめると！
LCPは5つのツールで測定でき、無料ツールでも十分把握できます。

有料・無料の測定ツールを目的に応じて使い分けることで、計測から改善までのサイクルを回しやすくなります。

LCPの測定方法には以下のものがあります。

• Lumar（旧：DeepCrawl）
• PageSpeed Insights
• Google Search Console
• Web Vitals
• Lighthouse

上記のうちLumar（旧：DeepCrawl）以外は無料ツールとなっています。

無料でもLCPの測定や最低限の課題の洗い出しは可能ですが、分析〜改善のサイクルを自動化させたい場合はやはり有料ツールが最適です。自社のリソースや目的に見合ったツールを適宜利用すると良いでしょう。

それでは各ツールについて詳しく見ていきます。

Lumar（旧：DeepCrawl）

Lumar（旧：DeepCrawl）はIKEAやNestle、Lenovoなどの企業にも導入されている世界水準のテクニカルSEOツールです。Lumar（旧：DeepCrawl）独自のクローラーが自社サイトをクロールし、検索順位に影響を与える様々な問題点を洗い出します。定期的なクロールの自動化機能や、タスク管理機能も備わっているため、サイト改善のPDCAサイクルを回すのも容易になります。

またLumar（旧：DeepCrawl）では、ページレンダリングサービス（PRS）の機能で、JavaScriptのレンダリングを検証することが可能です。検証にはGoogle botと同じ最新のGoogle Chromeを利用しているため、測定の正確性にも信頼が置けます。

後述するように、JavaScriptのレンダリングブロックはLCPスコアが低下する原因となります。そのため、Lumar（旧：DeepCrawl）のPRS機能は非常に貴重なのです。SEO会社に分析〜改善のすべてを丸投げする前に、Web担当者は一度導入を検討するべきツールだと言えるでしょう。

PageSpeed Insights

PageSpeed Insights は、パソコン・モバイル両方のページの読み込み速度を測定する無料ツールです。使い方は簡単で、トップページを開くとURL入力フォームがあるので、まずはそこに測定したいページのURLを打ち込みます。

「分析」をクリックすると、すぐに分析結果が表示されます。LCPの結果の他に、「改善できる項目」「診断」が列挙され、分析したサイトの改善点を把握することが可能です。

画面上部のパフォーマンススコアと、コアウェブバイタルの合否は別のデータで決まる点に注意が必要です。スコアはLighthouseによるラボデータ（固定条件で読み込みを再現した測定値）の評価で、合否は実際のユーザー環境から集めたフィールドデータで判定されます。

Google Search Console

Google Search Console は大まかに言えば、Googleがウェブサイトをどう評価しているかを把握するためのツールです。

具体的には、記事コンテンツなどのインデックス状況や平均順位、表示速度などのユーザビリティのレポート、セキュリティレポートなど、サイト運営に関わる様々な情報が集約されています。公式の無料ツールであることからも、Web担当者必携のツールであると言えます。

LCPとの関わりで言えば、Core Web Vitalsレポート（画面によっては「ウェブに関する主な指標」と表示されます）でページ読み込み速度のレポートを確認することができます。レポートは「良好」「改善が必要」「低速」の三段階で提示され、問題の状況を端的に把握することが可能です。

しかし、どのような改善が必要なのかは提示してもらえません。したがって具体的な改善策を把握するためには、別途PageSpeed Insightsを活用すると良いでしょう。自社サイトで実際にレポートを確認する手順はWEBサイトの描画速度の基準は？調べ方と改善方法を解説で解説しています。

Web Vitals

Web VitalsはGoogle Chromeの拡張機能として、開いているページのLCP・INP・CLSを自動計測できるツールでした。

ただし2026年8月時点、この拡張機能は新規に導入できません。公式リポジトリはChrome 132（2025年1月7日）でのサポート終了とアーカイブ（2025年2月3日）を明記しており、Chromeウェブストアの掲載ページも空欄タイトルへリダイレクトされ、掲載終了を確認しました。同等の計測はChromeのデベロッパーツール（DevTools）のPerformanceパネルで代替できます。

コアウェブバイタルの3指標（LCP・INP・CLS）を体系的に解説した記事はコアウェブバイタル（Core Web Vitals）とは？LCP・INP・CLSの意味＆ランキング改善方法を参考にしてください。

出典：web-vitals-extension（GitHub）

Lighthouse

Lighthouse はGoogleが提供するウェブページの品質をトータルに測定するツールです。

かつては「Progressive Web App」を含む要素を測定していましたが、2026年8月時点の公式ドキュメントでは「Performance」「Accessibility」「Best Practices」「SEO」を中心に構成されています。

このうちLCPに関わるのはPerformanceです。測定が完了すると、LCPのスコアを数値と、緑（良好）・黄（改善が必要）・赤（不良）の色分けで表示します。ただし、パフォーマンススコアの構成指標にINPは含まれないため、スコアが高いことはINPの合否を保証しません。

実行方法はデベロッパーツール・コマンドライン・Nodeモジュール・PageSpeed InsightsのWeb UIなど複数用意されています。別配布のChrome拡張機能もありますが、公式ドキュメントは「特別な理由がない限り拡張機能ではなくデベロッパーツールを使うこと」を推奨しています。

出典：Lighthouse の概要

ツールごとに測れるデータの種類は異なります。比較して選びたい場合はサイトスピード計測ツールおすすめ5選｜CWV合格基準と改善方法が判断材料になります。

LCPスコアが低下する原因

👉 このパートをまとめると！
LCP低下の原因は4つ。4つのサブパートで原因を切り分けられます。

原因を大枠で把握したうえで、サブパート診断にかけると改善の打ち手を選びやすくなります。

LCPスコアが低下する原因には以下のものがあります。

• サーバーの反応時間の遅延
• JavaScriptとCSSのレンダリングブロック
• リソースの読み込み時間の遅延
• クライアント側のレンダリング

上記のうち特に問題となりやすく、かつ対策による改善が見られやすいのが、「サーバーの反応時間の遅延」と「リソースの読み込み時間の遅延」です。

したがって次の「LCPの改善方法」の見出しでは、以上の2点を中心に改善方法を解説していきます。

一方で「JavaScriptとCSSのレンダリングブロック」と「クライアント側のレンダリング」は、JavaScriptの非同期化や、ファイルの軽量化、または不要なファイルの削除などによって対応が可能です。

それでは具体的な改善方法を見ていきましょう。

LCPは4つのサブパートに分解できる

上記の原因は、web.devが示す「LCPの4つのサブパート」という枠組みで整理すると切り分けやすくなります。LCPは、読み込み開始からLCP要素の描画完了までを次の4区間に分解できます。

※数値はweb.devがCrUXの実データから算出した、LCPが「良い」と判定されたオリジンのサブパートp75の中央値（画像がLCP要素となるページのデータ）です。Googleが示す配分の目安は、TTFB約40%・リソース読み込みの遅延10%未満・リソースの読み込み時間約40%・要素のレンダリングの遅延10%未満とされています。

出典：LCPに関するよくある誤解（web.dev Blog）・Largest Contentful Paint を最適化する（web.dev）

次の「LCPの改善方法」の4施策は、画像最適化・CDN配信化が主に「読み込み時間」、コード軽量化が「読み込み遅延」と「レンダリング遅延」に効きます。PageSpeed Insightsで長い区間を確認してから施策を選ぶと効率的です。

LCPの改善方法

👉 このパートをまとめると！
画像・コード・CDN・Lazy Loadの4方向から改善できます。

既存の4施策に2024年以降の実装（次世代フォーマットやpreload）を組み合わせると効果的です。

LCPの改善方法には次のものが有効です。

• 画像の最適化・圧縮
• コードの軽量化・圧縮
• 画像のCDN配信化
• Lazy Loadの設定

上記はどれもプラグインの追加や、コードの調整によって簡単に行えます。「LCPの改善は難しそう」と感じている方は、以降の見出しを参考にできそうなことから試してみましょう。

ただしやりっぱなしでは意味がありません。対策後は先に紹介した各種測定ツールを利用して、改善結果を確認するようにしてください。

それでは具体的な改善方法を見ていきましょう。

画像の最適化・圧縮

適切な処理が施されていない画像は、ページの読み込みを遅らせる主要因となっている場合が多いです。そこでLCPに問題があったときは、まずは画像の最適化・圧縮ができないかを検討しましょう。

スマートフォンなどで撮った写真などはサイズが大きいため、圧縮してから利用すべきです。またWordPressなどのCMSを利用している場合は、画像最適化・圧縮の各種プラグインを利用することで簡単に軽量化が行えます。

次世代フォーマット（WebPやAVIF）への変換も有効です。またLCP要素になる画像にはfetchpriority="high"属性を指定すると優先的に読み込まれます（付けすぎると効果が薄れるため対象を絞りましょう）。

出典：Optimize Largest Contentful Paint（web.dev）

コードの軽量化・圧縮

不要なコメントやスペースの削除などによって、コードの軽量化・圧縮ができないかも検討してみましょう。コードの圧縮にはCMSのプラグインや、フリーの圧縮ツールなどが利用可能です。

また少量のコードであれば、JavaScript/CSSを外部ファイルとして読み込むのではなく、インライン化することで全体として軽量化が行えます。

クリティカルCSS（表示に必要な最小限のCSS）を<head>内にインライン化し、それ以外はdefer/async属性で読み込むとレンダリングのブロックを減らせます。LCP要素になる画像やフォントには<link rel="preload">を指定すると早期に読み込みを開始できます。

出典：Optimize Largest Contentful Paint（web.dev）

画像のCDN配信化

画像のCDN配信化を行うことによって、オリジンサーバーの負荷が軽減され、結果として画像の読み込みスピードが向上します。CMSならばプラグインによって簡単にCDN配信化が可能です。または、imgタグのURLでCDNを指定するだけでも簡単に行えます。

CDNはユーザーに近いサーバーから配信するため、TTFB（Time to First Byte）の短縮にもつながります。TTFBやリソースの読み込み時間が長いページでは優先度の高い施策です。

Lazy Loadの設定

Lazy Loadとは、「遅延ロード」を行うためのJavaScriptライブラリのことです。

ブラウザは基本的に、指定されたURLのページに含まれる全ての画像を同時に読み込もうとします。しかし、ユーザーが最初に目にする画面の外にある画像の読み込みは本来不必要です。スクロールが当該画像に到達した時点で読み込みが完了していれば十分でしょう。

遅延ロードとは、以上の点を踏まえ、画像の読み込みに時間差を設けて画面表示の高速化を図る仕組みのことを指します。そしてLazy Loadを用いることで、遅延ロード処理を簡単に行うことが可能となるのです。

ただし、LCP要素になる画像自体にLazy Loadを適用してはいけません。web.devは「LCP 画像を遅延読み込みしないでください。遅延読み込みすると、常に不要なリソース読み込みの遅延が発生し、LCP に悪影響を及ぼします」と明記しています。画面外の2枚目以降の画像に限定し、最初に表示される主要画像には適用しないようにしましょう。

出典：Largest Contentful Paint を最適化する（web.dev）

INPやCLSの改善方法

👉 このパートをまとめると！
FIDは廃止済み。応答性はINP、視覚安定性はCLSで評価します。

指標名の読み替えと、それぞれの改善方針の要点を押さえておきましょう。

先述したとおり、Core Web Vitalsの要素はLCPの他にINPとCLSがあり、それぞれに対応した改善方法が存在します。

INP（Interaction to Next Paint＝インタラクションから次のペイントまでの時間）は、かつて使われていたFID（First Input Delay＝初回入力遅延）に代わる現行の応答性指標です。 INPは2024年3月12日に安定版のコアウェブバイタルとして採用され、FIDは2024年9月9日にサポートが終了しました。「LCP・FID・CLS」で覚えている資料が社内に残っている場合は、応答性の指標をINPに読み替える必要があります。

INPの改善はJavaScriptの実行量を減らし、処理に時間がかかるタスクを細分化することが基本方針です。FIDが最初の1回の操作しか測定しなかったのに対し、INPは滞在中のほぼすべての操作を対象にするため、検索や絞り込みなど操作の多い機能を持つページでは特に注意が必要です。

CLS（Cumulative Layout Shift＝累積レイアウトシフト）とはレイアウトのズレをスコア化したもので、サイズ指定のない画像や、動的コンテンツの多用が主な原因です。したがってHTML/CSSの調整や、動的コンテンツを少なくすることで改善が見込めます。CLSの計算方法や低下要因ごとの対処はコアウェブバイタルのCLSとは？問題と改善策を解説｜CLSの確認に便利なツールも紹介で詳しく解説しています。

出典：Interaction to Next Paint（INP）・INP becomes a Core Web Vital（web.dev Blog）

まとめ

👉 このパートをまとめると！
LCPは現行3指標の1つ。サブパート診断で効率的に改善できます。

測定から原因の切り分け、施策選定までの一連の流れを押さえておきましょう。

今後もSEOにおけるユーザーエクスペリエンスの重要性が高まるにつれて、Core Web Vitalsの現行3指標（LCP・INP・CLS）の1つであるLCPは、ますます無視できない指標となってきます。

本記事で解説してきたとおり、LCPの測定は無料ツールでも可能です。PageSpeed InsightsやGoogle Search Consoleで合否を確認し、不合格ならTTFB・読み込み遅延・読み込み時間・レンダリング遅延のどこで時間がかかっているかを切り分けてから、画像・コード・CDN配信の施策を選びましょう。

とはいえ、SEO対策は継続的に行うことが重要です。自社に十分なリソースがあり、測定〜改善のサイクルを自動化させたいのであれば、Lumar（旧：DeepCrawl）のような有料ツールの導入をぜひとも検討しましょう。

LCPに関するよくある質問

👉 このパートをまとめると！
LCPとFCPの違いや目標値など、よくある5つの疑問に回答します。

測定・判定でつまずきやすいポイントをQ&A形式で整理しました。

LCPとFCPの違いは？

LCPは「最大」のコンテンツが描画されるまでの時間、FCP（First Contentful Paint）は「最初」の何らかのコンテンツが描画されるまでの時間です。FCPは合否判定には使われませんが、LCPの遅延原因を診断する補助指標として役立ちます。

LCPが遅いと検索順位は下がる？

LCP単体で順位が決まるわけではありません。Google検索セントラルは「Core Web Vitals は、その他のページ エクスペリエンス要素とともに、Google のコア ランキング システムがランキングを決定する際に考慮する要素です」と説明する一方、「Google 検索は、ページ エクスペリエンスが平均を下回るコンテンツも含め、常に最も関連性の高いコンテンツが表示されるように設計されています」とも明記しています。

出典：Core Web Vitals と Google 検索の検索結果について・ページ エクスペリエンスと Google 検索結果への影響について

PageSpeed Insightsのスコアが高いのにLCPが不合格になるのはなぜ？

パフォーマンススコアはLighthouseのラボデータ（固定条件の再現測定）で算出されますが、コアウェブバイタルの合否は実ユーザーのフィールドデータのp75で判定されるためです。条件の良い環境のスコアが高くても、条件の悪い訪問が25%を超えれば不合格になります。

LCPの目標値は？

2.5秒以下が「良好」の目安です。web.devは2.5秒超4.0秒以下を「改善が必要」、4.0秒超を「不良」と定義しています。判定は実ユーザーの計測値のp75（75パーセンタイル）で行われます。

FIDはもう見なくていい？

コアウェブバイタルの判定には使われません。応答性の指標は2024年3月12日にINPへ置き換えられ、FIDは2024年9月9日にサポートが終了しました。「FIDは100ミリ秒以下」という記載はINPの基準（200ミリ秒以下）に読み替えてください。