# LCP改善の方法｜遅い原因の特定と画像・フォント・TTFBの最適化

元のページ: <https://chot-inc.com/knowledge/lcp-improvement>

サイト表示速度の改善方法｜Core Web Vitals対策ガイド

LCPを改善する方法を、遅い原因の特定から画像・フォント・TTFBの最適化まで解説します。大規模サイトやCMS構成でLCPが改善しにくい要因、制作会社に改善を依頼するときの確認事項、施策の優先順位と改善後の確認方法もまとめています。

## **はじめに**

LCP（Largest Contentful Paint）はCore Web Vitalsの中でも最も重要な指標で、多くのWebサイトでスコアが「要改善」または「不良」になっています。LCPが2.5秒を超えると訪問者の直帰率が上がり、SEOのスコアにも悪影響を与える。

本記事では、LCPが遅い原因を体系的に整理し、それぞれの具体的な改善方法を解説します。

## **LCPが遅い主な原因と対策の全体像**

LCPは「ページの最大コンテンツ要素が表示されるまでの時間」ですが、その改善は4つの領域に分類できます。

- サーバー応答時間（TTFB）の改善

- レンダリングブロックの解消

- LCP要素（画像）の最適化

- リソースの優先度設定

LPCを含むサイト表示速度の基礎については「[**サイト表示速度とは（UXとSEOへの影響）**](https://chot-inc.com//knowledge/what-is-site-speed)」で詳しく解説しています。

## LCPが遅い原因の特定方法｜計測の手順

LCPの改善は、原因を特定してから着手しないと効果が出ません。前の章で挙げた4つの原因のうち、どれが自社のサイトで起きているかを確認する手順を整理します。

1. PageSpeed Insightsで対象ページのURLを計測する。モバイルとデスクトップの両方を確認します

2. 結果の「Largest Contentful Paint要素」の項目で、どの要素がLCPとして判定されているかを確認する。多くの場合はファーストビューの画像か見出しです

3. LCPの内訳（Time to First Byte／リソースの読み込み待ち／リソースの読み込み／要素の描画）を確認する。どの区間に時間がかかっているかで原因が絞れます

4. TTFBが長い場合はサーバー応答、読み込み待ちが長い場合はレンダリングブロック、読み込みが長い場合は画像の最適化が主な対象になります

5. Chromeの開発者ツールでネットワークの通信を確認し、LCP要素の取得がいつ始まっているかを見る。開始が遅い場合は、その前に何が読み込まれているかを確認します

6. 実際の利用者のデータ（PageSpeed Insightsの上部に表示される実測値）と、計測値を比較する。両者が乖離している場合は、特定の環境でのみ遅い可能性があります

| 原因 | 症状の見え方 | 対処 | 効果の目安 |
| - | - | - | - |
| サーバー応答が遅い | TTFBが長い。どのページでも一様に遅い | CDNの導入、静的生成への切り替え、キャッシュ設定 | 構成の変更を伴うため効果は大きい一方、対応の負荷も大きい |
| レンダリングがブロックされている | LCP要素の読み込み開始が遅い | CSSの読み込み方の見直し、JavaScriptの非同期化 | 比較的短期間で対応でき、効果も出やすい |
| 画像が重い | LCP要素の読み込み時間が長い | フォーマットの変換、表示サイズに合わせた配信 | 対応が容易で、効果が数値に出やすい |
| 画像の読み込みが後回しになっている | LCP要素の取得開始が遅い | ファーストビューの画像で遅延読み込みを使わない、事前読み込みの指定 | 設定の変更のみで済む場合が多い |
| フォントの読み込みが遅い | 見出しがLCPの場合に描画が遅れる | 表示方法の指定、必要な字形に絞った配信 | 見出しがLCP要素の場合に有効 |

## **改善1：サーバー応答時間（TTFB）の短縮**

TTFB（Time to First Byte）はブラウザがサーバーへリクエストを送信してから最初のバイトを受け取るまでの時間です。LCPのすべてのプロセスはTTFBの後に始まるため、TTFBが長いとLCPも必ず長くなります。

目標値：600ミリ秒以下（理想は200ミリ秒以下）

### **対策1-1：CDNの活用**

CDN（Content Delivery Network）はユーザーに地理的に近いサーバーからコンテンツを配信することで、物理的な距離による遅延を削減します。

日本のユーザーが東京に設置されたVercelのエッジノードからコンテンツを受け取る場合と、アメリカのサーバーから受け取る場合では、ネットワーク遅延が大きく異なります。Vercelは世界100か所以上のエッジネットワークを持ち、日本ユーザーへの最適な配信を自動で行います。

#### CDNでLCPを改善する｜エッジ配信の効果と設定

前の章では、CDNがサーバー応答時間の短縮に有効であることに触れました。ここでは、実際に導入する際の設定と、効果を確認する方法を整理します。

CDNが効くのは、利用者とサーバーの物理的な距離が原因で待ち時間が生じている場合です。国内向けのサイトで、サーバーも国内にある場合は、距離による効果は限定的です。一方、画像やCSSといった静的ファイルの配信を任せることによる効果は、この場合でも得られます。

設定で最初に決めるのは、何をキャッシュするかです。画像、CSS、JavaScriptといった更新頻度の低いファイルは長めに、HTMLは短めに、または利用者ごとに内容が変わるページはキャッシュしない、という切り分けが基本になります。ここを誤ると、更新したのに古い内容が表示され続ける不具合が起きます。

更新時の反映方法も、導入前に決めておいてください。ファイル名に固有の文字列を含める方式にすると、更新したファイルは自動的に別のファイルとして扱われるため、キャッシュを消す作業が不要になります。

効果の確認は、導入前後で同じページを同じ条件で計測して比較します。特にTTFBの数値が改善しているかを見てください。TTFBが変わっていない場合は、原因がサーバー応答ではなかった可能性があります。

### **対策1-2：静的生成（SSG/ISR）の活用**

WordPressのような動的CMSは、アクセスのたびにPHPがデータベースを参照してHTMLを生成するため、TTFBが長くなりやすくなります。

Next.jsの静的生成（SSG）またはISR（Incremental Static Regeneration）を使うと、ビルド時にHTMLを事前生成してCDNから配信できるため、TTFBを100ミリ秒以下にできます。

### **対策1-3：サーバーキャッシュの設定**

動的なサーバー処理が必要な場合でも、適切なキャッシュ設定でTTFBを改善できます。

- HTMLのサーバーサイドキャッシュ（生成済みHTMLをキャッシュして再利用）

- データベースクエリのキャッシュ（Redis等）

- Vercelのエッジキャッシュ設定

## **改善2：レンダリングブロックの解消**

HTMLを描画する前にブラウザがCSSやJavaScriptを読み込む必要がある場合、これがLCPを遅らせます。

### **対策2-1：CSSのインライン化と非同期読み込み**

ファーストビューに必要なCSSだけをHTMLにインライン化し、残りのCSSを非同期で読み込みます。

Next.jsはデフォルトでコンポーネントに関連するCSSのみを必要なページに自動的に含める（CSS Modules・Tailwind CSSの場合）ため、この問題が起きにくい構造になっています。

### **対策2-2：JavaScriptの読み込みの最適化**

\<script> タグに defer または async 属性を追加することで、JavaScriptの実行がHTMLの描画をブロックしないようにします。

Next.jsでは next/script コンポーネントを使うことで、スクリプトの読み込みタイミング（beforeInteractive・afterInteractive・lazyOnload）を適切に制御できます。

## **改善3：LCP要素（画像）の最適化**

多くのサイトでLCPの原因はヒーロー画像等の大きな画像です。画像の最適化はLCP改善で最も効果が大きい施策の一つです。

### **対策3-1：画像フォーマットをWebPに変換する**

WebP（Google開発の画像フォーマット）はJPEGと同等以上の品質を保ちながら、ファイルサイズをJPEGより25〜34%削減できます。

Next.jsのnext/imageコンポーネントは、ブラウザがWebPに対応している場合に自動的にWebP形式で配信するため、手動での変換が不要です。

### **対策3-2：画像サイズを表示サイズに合わせる**

2,000×1,500ピクセルの画像を、実際には800×600ピクセルで表示している場合、不必要に大きなファイルをダウンロードしていることになります。

next/imageはsrcsetを自動生成して、デバイスの画面サイズに最適な解像度の画像を配信する（レスポンシブ画像）。

### **対策3-3：LCP画像に \`priority\` を設定する**

next/imageでは priority プロパティを設定することで、その画像をページ内で最優先で読み込むよう指示できます。

priority を設定すると、この画像に fetchpriority="high" と preload のリンクタグが自動的に追加されます。

### **対策3-4：画像の事前読み込み（Preload）**

next/imageの priority を使わずにカスタム実装する場合、\<link rel="preload"> タグをHTMLの \<head> に追加することでLCP画像を優先的に読み込めます。

## **改善4：ファーストビューの遅延読み込みを無効にする**

「遅延読み込み（Lazy Loading）」はスクロールして画面に入ったときに画像を読み込む最適化技術ですが、ファーストビュー（最初の画面）の画像に設定すると逆効果になります。

ファーストビューの画像には loading="eager" または priority プロパティを設定し、スクロールしないと見えない画像には loading="lazy" を設定します。

## **LCP改善の実施順序**

LCPの改善施策を実施する際の優先順位を示す。

#### **最優先（即効性高）**

- LCP画像への priority プロパティの設定（Next.js）

- 画像のWebP変換・サイズ最適化

- ファーストビュー画像の遅延読み込み無効化

#### **高優先（効果大）**

- CDNの導入・静的生成（SSG/ISR）への移行

- レンダリングブロックするCSS・JavaScriptの特定と解消

#### 中優先（根本的な改善）

- サーバー応答速度（TTFB）の改善

- 技術スタックの見直し（WordPress→Next.js+Vercel等）

### **改善効果の目安**

適切な最適化を実施した場合の改善効果の目安を示します。

| **施策** | **LCP改善の目安** |
| - | - |
| LCP画像へのpriority設定 | 0.3〜0.8秒短縮 |
| 画像のWebP変換 | 0.2〜0.5秒短縮 |
| CDN導入（Vercel等） | 0.5〜1.5秒短縮 |
| SSG/ISRへの移行（WordPressから） | 1〜3秒短縮 |
| レンダリングブロック解消 | 0.3〜1.0秒短縮 |

複数の施策を組み合わせると、LCP 4〜5秒台のサイトが1〜2秒台になることも現実的に達成できます。

### 改善前後の確認方法

改善作業を行ったあと、効果が出ているかを確認する手順を決めておいてください。計測のたびに数値が変わるため、1回の計測結果で判断すると誤った結論になります。

計測は、同じページ、同じ端末の設定、同じ時間帯で、複数回行って比較します。PageSpeed Insightsの数値は計測ごとにばらつくため、3回程度計測して中央の値を見るのが実務的です。

あわせて、実際の利用者のデータも確認してください。これは過去一定期間の実測を集計したものなので、改善が反映されるまでに時間がかかります。作業直後に変化がなくても、数週間の単位で推移を見る必要があります。

Search Consoleのウェブに関する指標のレポートでは、改善が必要なURLがどの程度減ったかを確認できます。個別ページの数値ではなく、サイト全体としての改善状況を見る場合はこちらが適しています。

なお、Core Web Vitalsの各指標の目標値はGoogleが公表しているものです。基準は改定されることがあるため、最新の公表内容をご確認ください。

## フレームワーク別の対応（Next.js・WordPress）

LCPの改善方法は共通していますが、実際にどこを触るかは使っている仕組みによって変わります。

Next.jsの場合は、画像の最適化とページの生成方式が主な対象になります。画像コンポーネントを使うと、表示サイズに合わせた配信とフォーマットの変換が自動化されます。ファーストビューの画像には優先読み込みの指定を行い、遅延読み込みが適用されないようにします。ページの生成方式は、更新頻度の低いページをあらかじめ生成しておく方式に変えることで、TTFBを短縮できます。

WordPressの場合は、プラグインとテーマの見直しが中心になります。有効化しているプラグインが多いほど、読み込むファイルが増えて表示が遅くなります。使っていないプラグインを停止するだけで改善する場合もあります。画像については、アップロード時に自動で変換する仕組みを導入し、表示サイズに合わない大きな画像がそのまま配信されない状態にしてください。

どちらの場合も、レンタルサーバーの性能が原因になっていることがあります。プラグインや画像を最適化してもTTFBが改善しない場合は、サーバーの見直しが必要な段階です。

## 大規模サイト・CMS構成でLCPが改善しにくい要因

ページ数の多い企業サイトでは、技術的な対策がわかっていても、LCPの改善が思うように進まないことがあります。原因は個別のページではなく、テンプレートの共通部分やCMSの運用ルール、部署ごとに追加される外部タグにあることが多いためです。

よくあるのは、CMSから入稿された画像がそのままの大きさで配信されているケースです。編集担当者が大きな画像を登録すると、テンプレート側で最適化していても効果が薄れます。入稿時に自動で変換・縮小する仕組みや、ファーストビュー画像の推奨サイズを運用ルールとして定めておくことが大切です。[**ヘッドレスCMSとは何か**](https://chot-inc.com/knowledge/headless-cms-explained)を含め、CMSと表示の仕組みを分ける構成も選択肢になります。

広告や計測、チャットなどの外部タグもLCPを遅らせます。部署ごとにタグマネージャーへ追加されたタグが整理されないまま残っていると、ファーストビューの描画を妨げます。利用者ごとに表示を変える仕組みを入れている場合は、ページをキャッシュできずCDNの効果が出ないこともあります。[**CDN・エッジキャッシュの考え方**](https://chot-inc.com/knowledge/cdn-edge-cache)とあわせて、キャッシュできるページとできないページを切り分けてください。

- CMSから入稿される画像の大きさと形式が統一されていない

- 共通テンプレートのファーストビューに重い要素が載っている

- 部署ごとに追加された外部タグが整理されていない

- 利用者ごとに表示を変える仕組みがあり、ページをキャッシュできない

## 制作会社にLCP改善を依頼するときの確認事項

LCPの改善を外部に依頼する場合、最初に改善の対象と成果の確認方法をそろえておかないと、作業が終わっても効果を判断できません。依頼の前に、どのページを対象にし、どの数値で効果を確認するかを決めておきます。

対象は個別のURLではなく、テンプレート単位で指定すると効率的です。同じテンプレートを使うページはまとめて改善されるため、アクセスの多いテンプレートから順に着手できます。改善前の計測値を基準として共有し、同じ条件で再計測する約束をしておくと、効果の確認で認識の差が出にくくなります。

あわせて、作り直さずに対応できる範囲と、構成の見直しが必要な範囲を分けて提案してもらってください。外部タグの整理やCMSの運用ルールの変更は発注側の作業になるため、誰が対応するかも決めておきます。進め方の全体像は「[**表示速度改善プロジェクトの進め方**](https://chot-inc.com/knowledge/speed-improvement-project)」で解説しており、Next.jsへの技術移行を含めた相談は[**モダンWeb開発の支援**](https://chot-inc.com/services/modern-web-development)でも受け付けています。

- 改善の対象にするページまたはテンプレート

- 改善前の計測値と、効果を確認する計測条件

- 作り直さずに対応できる範囲と、構成の見直しが必要な範囲

- 外部タグの整理やCMSの運用ルール変更を誰が担当するか

- 改善後に数値が悪化していないかを確認する体制

## **まとめ**

LCPの改善は「LCP画像へのpriority設定と画像最適化（即効性あり）」から始め、「CDN・静的生成による根本的なアーキテクチャ改善（中長期）」へと段階的に進めることが効果的です。

Next.jsのnext/imageは、WebP変換・レスポンシブ画像・priority設定・遅延読み込みをすべて自動化するため、LCP改善において非常に強力なツールです。

次の記事では、LCPと並んでパフォーマンスに大きく影響する「画像最適化」の完全ガイドを解説します。

## よくあるご質問

表示速度は評価の要素の1つですが、順位を決める要素はほかにも多くあります。内容の質が同程度のページ同士では差が出る可能性がある、という位置づけです。速度の改善は、順位よりも離脱率や問い合わせ数への影響を期待して取り組むほうが実態に合います。

Googleが公表している「良好」の基準を目安にしてください。ただし、まず取り組むべきは基準を大きく超えているページです。全ページを一律に改善しようとせず、アクセスの多いページから着手するほうが効果が見えやすくなります。

計測時に想定している通信環境と端末性能が異なるためです。モバイルの計測は、通信速度を制限した条件で行われます。実際の利用者にモバイルが多い場合は、モバイル側の数値を優先して改善してください。

原因の特定が誤っていた可能性があります。上の計測手順に戻り、LCP要素として判定されている要素と、時間がかかっている区間を確認し直してください。画像を最適化してもTTFBが長いままであれば、対処すべきはサーバー側です。

画像の最適化、読み込み順の調整、キャッシュの設定は、作り直さずに対応できる範囲です。一方、ページの生成方式そのものが原因の場合は、構成の変更が必要になります。まず作り直さずにできる範囲で計測し、それでも目標に届かない場合に構成の見直しを検討する順序をおすすめします。

影響する場合があります。外部タグの読み込みや実行がファーストビューの描画と重なると、LCPが遅れます。使われていないタグを停止し、残すタグも読み込みのタイミングを遅らせられないかを確認してください。

入稿時に画像を自動で変換・縮小する仕組みを導入するのが確実です。あわせて、ファーストビューに使う画像の推奨サイズを編集担当者向けのルールとして共有しておくと、担当者が変わっても品質を保ちやすくなります。

定期的に主要なテンプレートの数値を計測し、悪化したときに気づける状態にしておくことが大切です。新しい外部タグの追加やデザインの変更を行う際に、表示速度への影響を確認する手順を運用ルールに組み込んでおくと、悪化を防ぎやすくなります。

画像の差し替えや不要なタグの停止は社内でも対応できます。一方、テンプレートの改修やページの生成方式の変更など、構成に関わる対応は専門の知識が必要です。原因の特定までを社内で行い、構成の見直しが必要とわかった段階で外部への依頼を検討する進め方もあります。

## エージェント型Web・AIアプリ 開発のご相談

chot inc.ではエージェント型Webの設計・構築・ 運用を 一貫してサポートしています。

[お問い合わせ](https://chot-inc.com/contact)

## このテーマの他の記事

- ### [サイト表示速度とは？なぜUXとSEOの両方に影響するのか](https://chot-inc.com/knowledge/what-is-site-speed)
  [サイト表示速度とは何か、なぜUXとSEOの両方に影響するのかを解説します。直帰率・CV率・Core Web Vitalsのランキング要因としての位置づけ・速度が遅くなる6つの原因をまとめています。](https://chot-inc.com/knowledge/what-is-site-speed)
- ### [Core Web Vitalsとは？LCP・INP・CLSの意味と目標値](https://chot-inc.com/knowledge/core-web-vitals-explained)
  [Core Web VitalsのLCP・INP・CLSの意味と目標値を解説します。各指標の定義・良好・要改善・不良の基準・悪化する原因・Field DataとLab Dataの違いをまとめています。](https://chot-inc.com/knowledge/core-web-vitals-explained)
- ### [Lighthouseの使い方｜スコアの見方と表示速度の改善手順](https://chot-inc.com/knowledge/lighthouse-guide)
  [LighthouseとはGoogleのパフォーマンス計測ツールです。PageSpeed Insights・Chrome DevTools・CLIの3つの起動方法・スコアの読み方・改善サイクルの回し方をまとめています。](https://chot-inc.com/knowledge/lighthouse-guide)

[サイト表示速度の改善方法｜Core Web Vitals対策ガイド一覧](https://chot-inc.com/knowledge/themes/web-performance)