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

はじめに

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

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

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

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

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

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

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

• リソースの優先度設定

LPCを含むサイト表示速度の基礎については「サイト表示速度とは（UXとSEOへの影響）」で詳しく解説しています。

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の上部に表示される実測値）と、計測値を比較する。両者が乖離している場合は、特定の環境でのみ遅い可能性があります

改善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 4〜5秒台のサイトが1〜2秒台になることも現実的に達成できます。

改善前後の確認方法

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

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