Largest Contentful Paint (LCP) の問題を特定して修正する

このガイドは Largest Contentful Paint (LCP) ハブの一部です。LCPは、最も大きな表示要素がレンダリングされるまでの速度を測定します。Googleはこれを2.5秒未満にすることを推奨しています。以下は、私がページスピードのコンサルティングを行う際に使用する正確な診断プロセスです。

LCPの診断と修正のためのコンサルタントガイド

私の名前はArjen Karelで、ページスピードコンサルタントです。長年にわたり何百ものウェブサイトを監査してきましたが、最も根強い課題の1つが Largest Contentful Paint (LCP) です。このガイドでは、LCPの問題を診断して解決するために私が使用している正確な方法論を共有します。このプロセスのために必要な正確なデータを取得するために私が作成したRUMツールである CoreDash についての言及が出てきます。ここでの原則は普遍的ですが、私が日々構築し使用しているツールからの実際の例を示すことが重要だと考えています。

LCPの改善は消去法です。2025 Web Almanac によると、モバイルのオリジンの66%しかLCPに合格していません。つまり、ウェブの3分の1に読み込みの問題があることになります。最も遅いフェーズを見つけ、修正し、再度測定します。

診断方法論：フィールドデータが先、ラボデータは後

効果的に最適化するには、2段階の診断ワークフローを採用する必要があります。これにより、ラボ環境でスコアを追いかけるだけでなく、ユーザーが直面している実際のユーザーの問題を解決できます。

1. フィールドデータ (RUM & CrUX) は「何が起こっているか」を示します。 フィールドデータはサイトを訪れる実際のユーザーから収集されます。LCPの問題があるかどうか、どのページが影響を受けているか、どのユーザー（モバイルまたはデスクトップ）がそれを経験しているかを示します。実際の問題が存在することを確認するために、常にここから開始する必要があります。
2. ラボデータ (Lighthouse、DevTools) は「なぜ起こっているか」を診断するのに役立ちます。 ラボデータは、Lighthouseなどのツールを使用して制御されたシミュレート環境で収集されます。フィールドデータが特定のページでの問題を確認したら、ラボツールを使用して問題を一貫して再現し、読み込みプロセスを分析して根本原因を見つけることができます。

最適化の取り組みが実際のユーザーに影響を与える変更を確実に対象とするように、フィールドデータから始めてください。

ステップ 1: フィールドデータでLCPの問題を特定する

最初のタスクは、実際のユーザーデータを使用して、どのページでLCPが悪いか（ある場合）を確認することです。

アクセスしやすい出発点: Google Search Console

有効な出発点は、Google Search Consoleの Core Web Vitals レポートです。ログインしてレポートに移動し、モバイルとデスクトップのグラフを確認します。Googleが「LCPの問題: 2.5秒超」とURLにフラグを立てている場合、Chrome User Experience (CrUX) Reportから、一定割合のユーザーが悪いユーザーエクスペリエンスを経験していることが確認できます。

Search Consoleは問題を確認しますが、更新が遅く、URLをグループ化します。リアルタイムでのページレベルの詳細については、RUMツールが必要です。

Real User Monitoring (RUM): ページレベルの詳細

web-vitals library を使用して独自のRUMセットアップを構築し、分析バックエンドにデータを送信することもできますが、それはかなりのエンジニアリングの労力を要します。

私はこれに特化した CoreDash を構築しました。1つのスクリプトタグを追加すると、ページ、デバイス、要素ごとに分類されて、すべての実際の訪問者からLCPデータの収集が開始されます。

優れたRUMツールを使用すると、次のことがわかります。

• 特定のURLに対する正確なLCPスコア。
• すべてのLCP要素（画像、見出しなど）のブレークダウンと、遅いLCPに最も頻繁に関連付けられている要素。
• すべてのページビューに対する4つのLCPフェーズごとの正確なタイミングで、ボトルネックを特定します。

LCP要素自体を超えて見ることが重要です。十分に文書化されたケーススタディでは、VodafoneはLCPを31%改善し、これが売上の8%増加に直接貢献しました。彼らの最適化は、フィールドデータ分析とターゲットを絞った修正を組み合わせて、主要なランディングページの特定のLCPボトルネックを特定して解決することに焦点を当てていました。LCPの最適化は画像だけではありません。サーバーの応答、リソースの発見、ダウンロード、ペイントなど、読み込みパイプライン全体を理解する必要があります。

たとえば、CoreDashでは、LCPページに移動して、最も遅いLCP要素を示すデータテーブルを表示できます。特定の要素（ヒーロー画像の特定のCSSクラスなど）をクリックすると、すべてのメトリクスをフィルタリングして、その要素がLCPであったページのパフォーマンスデータのみを表示できます。

目標：フィールドデータを使用して、最も遅いページと最も一般的なLCP要素を見つけることです。それがあなたのターゲットです。

Performance Observer APIでLCPを測定する

Performance Observer APIを使用すると、JavaScriptでLCPエントリに直接アクセスできます。これは、RUMツールがフィールドデータを収集するために内部で使用するのと同じAPIです。次のスニペットは、要素、そのサイズ、レンダリング時間など、ブラウザが特定するすべてのLCP候補をログに記録します。

const observer = new PerformanceObserver((list) => {
  const entries = list.getEntries();
  const lastEntry = entries[entries.length - 1];
  console.log('LCP element:', lastEntry.element);
  console.log('LCP time:', lastEntry.renderTime || lastEntry.loadTime);
  console.log('LCP size:', lastEntry.size);
});
observer.observe({ type: 'largest-contentful-paint', buffered: true });

これは開発中の迅速な検証に役立ちますが、本番環境の測定には web-vitals library を使用する必要があります。これにより、タブの表示状態の変更やback/forward cacheの復元などのエッジケースが処理されます。

ステップ 2: ラボツールでボトルネックを診断する

どのページを修正すべきかはわかりました。次はなぜ遅いのかを突き止めます。PageSpeed Insights またはChrome DevToolsのLighthouseパネルでテストを実行します。

レポートで、「Diagnostics（診断）」セクションまで下にスクロールし、「Largest Contentful Paint element（最大コンテンツの描画要素）」の監査を見つけます。このウォーターフォールチャートは、LCP時間を4つのサブパートに分解します。RUMツールでも、フィールドデータに基づいて同様のブレークダウンが表示されるはずです。

目標は、このブレークダウンで最も長いフェーズを見つけることです。それがあなたの主要なボトルネックであり、最初に最適化の努力を集中すべき場所です。

ステップ 3: 4つのLCPフェーズを理解する

すべてのLCPスコアは、4つの連続したフェーズの合計です。各フェーズには、特定の最適化手法をカバーする専用のガイドがこのサイトにあります。

• Time to First Byte (TTFB): これはスキップできない基礎です。サーバーの応答が遅いと、LCPにミリ秒単位で直接加算されます。1つの画像を最適化する前に、サーバーが迅速に応答していることを確認する必要があります。TTFBの最適化について詳しく学んでください。
• Resource Load Delay: これは「発見の問題」であり、最も一般的な問題の1つです。ブラウザは知らないリソースをダウンロードすることはできません。LCP画像がCSSやJavaScriptファイルに隠れている場合、またはHTML内にあるが他のリソースが先にリクエストされる場合、ブラウザが画像を見つけるのが遅すぎ、貴重な時間を無駄にします。Resource Load Delayに関する完全なガイドをお読みください。
• Resource Load Duration: これはLCPリソース自体のダウンロード時間です。圧縮されていない大きな画像や、ネットワークの状態が悪いと、このフェーズがボトルネックになる可能性があります。Resource Load Durationに関する完全なガイドをお読みください。
• Element Render Delay: これは「ペイントに忙しすぎる」問題です。LCP画像ファイルは完全にダウンロードされているかもしれませんが、ブラウザのメインスレッドが重いJavaScriptの実行によってブロックされていると、単に画像を画面にペイントする処理に取り掛かることができません。Element Render Delayに関する完全なガイドをお読みください。

ファイルサイズやレンダリングの最適化に進む前に、常にTTFBが高速であり、LCPリソースが発見可能であることを確認することから始めてください。

ステップ 4: 修正を実行する

ボトルネックを特定したら、修正を適用します。実装はスタックによって異なります。以下の各フェーズでは、最初に普遍的な原則をカバーし、次にWordPressとJSフレームワークの特記事項をカバーしています。

1. Time to First Byte (TTFB) の最適化

TTFBが遅い場合（良い目標は800ミリ秒未満です）、LCPの高い下限が設定されてしまいます。TTFBを改善すると、他のすべての読み込みメトリクスが改善されます。

普遍的なTTFBのソリューション

• キャッシュを有効にする: これはTTFBを改善する最も効果的な方法の1つです。キャッシュはページのコピーを生成して保存するため、訪問のたびにサーバーがゼロから構築するのを待つことなく、即座に提供できます。
• CDNを使用する: コンテンツデリバリーネットワークは、ユーザーに物理的に近いサーバーからコンテンツを提供し、ネットワークのレイテンシを削減します。CDNのエッジで完全なHTMLページをキャッシュすることは、高速でグローバルなTTFBのための強力な戦略です。詳細なCDNの設定のヒントについては、最適なパフォーマンスのためにCloudflareを設定する方法のガイドを参照してください。
• BrotliまたはGzip圧縮を使用する: サーバーがHTML、CSS、JavaScriptなどのテキストベースのアセットを圧縮していることを確認してください。BrotliはGzipよりも優れた圧縮を提供するため、優先して使用する必要があります。
• 0-RTTでHTTP/3を使用する: サーバーがHTTP/3を使用するように構成されていることを確認してください。より優れたマルチプレクシングなど、大きなパフォーマンスの利点があります。0-RTT（Zero Round Trip Time Resumption）をサポートしており、リピーターの接続セットアップ時間を排除し、瞬時のTTFBブーストを提供します。
• 103 Early Hintsを使用する: 高度なブーストには、103 Early Hintsステータスコードを使用します。これにより、ブラウザが完全なHTMLドキュメントの準備をしている間に、サーバーまたはCDNが重要なCSSおよびJSファイルに関するヒントをブラウザに送信でき、ダウンロードをさらに早く開始できるようになります。完全な実装ガイドについては、103 Early Hintsに関する記事を参照してください。

プラットフォーム固有のTTFBの修正

WordPressの場合:

• 高品質のホスティングに投資する: WordPressでは、遅いTTFBはホスティング環境に関連していることがよくあります。安価な共有ホスティングがボトルネックになる可能性があります。パフォーマンスに最適化されたマネージドWordPressホストを検討してください。
• キャッシュプラグインを使用する: 高品質のキャッシュプラグイン（WP Rocket、W3 Total Cacheなど）は必須です。これは静的HTMLファイルの生成を処理し、これがこのプラットフォームでの効果的なキャッシュのコアとなります。

JSフレームワークの場合:

• 適切なホスティングプラットフォームを選択する: Node.jsアプリケーションの場合、VercelやNetlifyなどのプラットフォームはSSR/SSGフレームワーク用に高度に最適化されており、インテリジェントなキャッシュとサーバーレス関数の実行を標準で提供します。
• SSRキャッシュを実装する: サーバーサイドレンダリングを使用している場合は、リクエストのたびに再レンダリングを避けるために、レンダリングされたページをサーバー（Redisやインメモリキャッシュなど）にキャッシュします。
• サーバーレスのコールドスタートに注意する: レンダリングにサーバーレス関数を使用している場合、「コールドスタート」（非アクティブ期間後の最初のリクエスト）が高いTTFBを持つ可能性があることに注意してください。プロビジョニングされた同時実行やキープアライブ戦略を使用してこれを軽減します。

2. Resource Load Delay を減らす

これが最も大きなボトルネックになることが頻繁にあります。つまり、ブラウザは作業する準備ができていたのに、メイン画像やフォントファイルをすぐに見つけられなかったということです。この遅延は通常、2つの問題のいずれかによって引き起こされます。リソースの発見が遅いか、ダウンロードの優先度が低く設定されているかです。このトピックの完全なガイドについては、Resource Load Delayに関する専用ガイドをお読みください。

普遍的なLoad Delayのソリューション

Resource Load Delayの普遍的な解決策は、LCPリソースが初期のHTMLマークアップで発見可能であり、ブラウザによって高い優先度が与えられていることを確認することです。これを達成する方法は次のとおりです。

• LCPリソースを発見可能にする: 最も重要なステップは、サーバーが送信するHTMLにLCP要素が存在することを確認することです。ブラウザは高速の「プリロードスキャナー」を使用して、生のHTMLを先読みし、画像やスクリプトなどのダウンロードするリソースを探します。LCP画像がCSSの background-image 経由で読み込まれたり、JavaScriptで挿入されたりすると、このスキャナーには見えず、大きな遅延が発生します。最も堅牢な解決策は、サーバーでレンダリングされたHTMLで、src 属性を持つ標準の <img> タグを常に使用することです。
• preload で読み込み順序を制御する: LCPリソースを直接発見可能にできない場合（フォントやCSSの背景画像でよくある問題）、次善の策は <link rel="preload"> を使用することです。このタグはHTMLの <head> 内で明示的な指示として機能し、自然に見つけるよりもはるかに早く重要なリソースのダウンロードを開始するようにブラウザに伝えます。実装の詳細と例については、LCP画像をプリロードする方法のガイドを参照してください。
• fetchpriority で高い優先度を確保する: リソースが発見可能であっても、ブラウザがそれに最高のダウンロード優先度を与えない場合があります。<img> タグまたは <link rel="preload"> タグに fetchpriority="high" を追加することは、この特定のリソースがユーザーエクスペリエンスにとって最も重要であるというブラウザへの強力なヒントであり、他のリソースとの帯域幅の競争に勝つのに役立ちます。

プラットフォーム固有のLoad Delayの修正

WordPressの場合:

• ページビルダーの背景画像を避ける: 多くのページビルダーでは、ヒーロー画像を div のCSS background-image として簡単に設定できます。これにより、ブラウザのプリロードスキャナーからは見えなくなります。可能であれば、代わりに標準の <img> ブロックを使用してください。そうでない場合は、その特定の画像をプリロードするためのプラグインまたはカスタムコードが必要になる場合があります。
• LCP画像の遅延読み込み(Lazy-Loading)を無効にする: 多くの最適化プラグインは、すべての画像を自動的に遅延読み込みします。プラグインの設定を見つけて、LCP画像（そして多くの場合、ページ上の最初の数枚の画像）を遅延読み込みから除外する必要があります。これは非常によくある間違いであるため、遅延読み込みされたLCP画像の修正に関する専用の記事があります。

JSフレームワークの場合:

• Server-Side Rendering (SSR) を使用する: これが最も影響力のある修正であることがよくあります。デフォルトの Client-Side Rendered (CSR) のReactアプリは最小限のHTMLを送信し、LCP要素は大規模なJSバンドルがダウンロードされて実行された後にのみ存在します。Next.jsやRemixなどのSSRフレームワークは、<img> タグを含む完全なHTMLを配信するため、ブラウザはすぐにそれを発見できます。
• フレームワーク固有の画像コンポーネントを使用する: Next.jsなどのフレームワークは、priority プロップを持つ画像コンポーネントを提供します。priorityプロップを使用すると、fetchpriority="high" やその他の最適化がLCP画像に自動的に適用されます。

3. Resource Load Duration を短縮する

LCPリソースを可能な限り小さく保つことは、依然としてプロセスの不可欠な部分です。このフェーズは、ネットワーク経由でLCPリソースファイルをダウンロードするのにかかる時間に関するものです。画像最適化手法の完全なガイドについては、LCP画像の最適化に関する記事、および具体的に Resource Load Duration についての記事を参照してください。

普遍的なLoad Timeのソリューション

• 最新のフォーマットとレスポンシブ画像でファイルサイズを縮小する: ダウンロード時間を短縮する最も直接的な方法は、ファイルを小さくすることです。画像の場合、これはAVIFやWebPなどの最新の高効率フォーマットを使用することを意味します。また、<picture> 要素または srcset および sizes 属性を使用して、レスポンシブ画像を提供する必要があります。これにより、モバイルデバイスを使用しているユーザーは、デスクトップサイズの巨大な画像を強制的にダウンロードさせられるのではなく、小さな画面に合わせて適切にサイズ調整された画像を受け取ることができます。幅400ピクセルのモバイル画面には、幅2000ピクセルの画像ファイルは単に必要ありません。テキストベースのLCPの場合、フォントが効率的なWOFF2形式であり、未使用の文字を削除するためにサブセット化されていることを確認してください。
• ネットワークの競合を減らす: LCPリソースは、ユーザーの限られたネットワーク帯域幅を巡って競合する必要があります。分析スクリプトやファーストビューより下のコンテンツのCSSなど、重要でないリソースを遅延させることで帯域幅が解放され、ブラウザがLCPリソースの高速なダウンロードに集中できるようになります。
• 重要なリソースをメインドメインでホストする: 可能であれば、LCPリソースを別のドメインから読み込むことは避けてください。別のサーバーへの新しい接続を設定すると、時間のかかるDNSルックアップとハンドシェイクが追加されます。

プラットフォーム固有のLoad Timeの修正

WordPressの場合:

• 画像最適化プラグインを使用する: ShortPixelやSmushなどのツールを使用すると、アップロード時に画像を自動的に圧縮し、WebP/AVIFなどの最新のフォーマットに変換し、レスポンシブな srcset サイズを生成できます。
• 手動で画像のサイズを変更する: アップロードする前に、画像のサイズを必要以上に大きくならないように変更します。最大の画面で1200pxの幅しかないスペースに、4000pxの幅の画像をアップロードしないでください。

JSフレームワークの場合:

• 画像CDNを使用する: これは強力なソリューションです。Cloudinary、Imgix、またはAkamaiのImage & Video Managerなどのサービスを使用すると、最適化プロセス全体を自動化できます。高品質の画像を1つアップロードすると、高速CDNを介して、各ユーザーに完全にサイズ調整、圧縮、およびフォーマットされたバージョンが配信されます。
• ビルドツールを活用する: 最新のフレームワークでコンポーネントに画像をインポートすると、ビルドツール（WebpackやViteなど）はビルドプロセスの一部としてファイルを自動的にハッシュ化および最適化できます。

4. Element Render Delay を短縮する

リソースのダウンロードは完了しましたが、まだ画面に表示されていません。これは、ブラウザのメインスレッドが他のタスクで忙しく、要素をペイントできないことを意味します。これも非常に一般的で重大なボトルネックです。完全なガイドについては、Element Render Delayに関するガイドをお読みください。

普遍的なRender Delayのソリューション

• 未使用のJavaScriptを遅延または削除する: ページの最初の表示部分をレンダリングするために不可欠でないJSはすべて、defer または async 属性を使用して遅延させる必要があります。
• クリティカルCSSを使用する: 大規模でレンダリングブロックするスタイルシートは、レンダリングを遅らせる可能性があります。クリティカルCSS技術では、ファーストビューのコンテンツをスタイルするために必要な最小限のCSSを抽出し、それを <head> にインライン化し、残りのスタイルを非同期で読み込みます。
• 長いタスクを分割する: 実行時間の長いスクリプトは、メインスレッドを長期間ブロックし、レンダリングを妨げる可能性があります。これは、Interaction to Next Paint (INP) が悪化する主な原因でもあります。コードをより小さく、非同期のチャンクに分割し、メインスレッドに yield（処理を譲る）するようにします。

プラットフォーム固有のRender Delayの修正

WordPressの場合:

• プラグインを監査する: プラグインが多すぎると、特にスライダーや複雑なページビルダーなどの重いプラグインの場合、メインスレッドをブロックする大量のCSSとJSが追加される可能性があります。プラグインを1つずつ非アクティブにして、パフォーマンスを低下させている原因を特定します。
• 軽量のテーマを使用する: 使用していない数十の機能を備えた肥大化したテーマは、レンダリングブロックコードの主な原因となる可能性があります。パフォーマンス重視のテーマを選択してください。
• プラグインアセットマネージャーを使用する: Asset CleanUpやPerfmattersなどのツールを使用すると、必要のないページで特定のプラグインのCSSとJSを条件付きで無効にすることができます。

JSフレームワークの場合:

• コード分割が重要: アプリのすべてのJavaScriptを1つの巨大なバンドルとして送信しないでください。ルートごと（ユーザーが訪問しているページのコードのみをダウンロードするように）およびコンポーネントごとにコードを分割します。
• コンポーネントを遅延読み込みする: React.lazy と Suspense を使用して、すぐには表示されないコンポーネント（ファーストビューより下のコンポーネントやモーダル内など）を遅延読み込みします。これにより、初期バンドルからそれらを除外できます。

高度なトピック: その後のナビゲーションでのLCPの最適化

最初のLCPを修正することは重要ですが、その後のページ読み込みを最適化することで、サイトのブラウジングを瞬時に感じさせることができます。

ページがBack/Forward Cache (bfcache)の対象であることを確認する

bfcacheはブラウザの最適化機能であり、ユーザーが移動したときにページの完全なスナップショットをメモリに保存します。戻るボタンをクリックすると、ページを瞬時に復元できるため、LCPはほぼゼロになります。unload イベントリスナーなどにより、多くのページがこのキャッシュの対象外になっています。Lighthouseの「bfcache」監査を使用してページをテストし、ブロックしている機能をすべて削除します。

PrerenderingにSpeculation Rules APIを使用する

Speculation Rules APIを使用すると、ユーザーが次に移動しそうなページを宣言的にブラウザに伝えることができます。ブラウザはこれらのページをバックグラウンドでフェッチして事前レンダリング（prerender）できます。ユーザーが事前レンダリングされたページへのリンクをクリックすると、ナビゲーションは瞬時に行われ、ほぼゼロのLCPにつながります。これらのルールは、HTMLの <script type="speculationrules"> タグで定義できます。

<script type="speculationrules">
 {
  "prerender": [{
   "source": "document",
   "where": {
    "href_matches": "/products/*"
   },
   "eagerness": "moderate"
  }]
 }
 </script>  

この例では、現在のページで商品ページへのリンクを探し、ユーザーがリンクにホバーしたときに事前レンダリングを開始するようにブラウザに指示しています。

4つのフェーズを順番に進めてください。最大のボトルネックを最初に修正し、再度測定して繰り返します。

次のステップ: 各LCPフェーズの詳細

各LCPフェーズには独自のガイドがあります。

• LCP画像の最適化: 画像形式の選択、レスポンシブ画像、プリロード、および一般的な画像最適化の間違いに関する完全なガイド。
• Resource Load Delay: preload、fetchpriority、および適切なHTML構造を使用して、ブラウザがLCPリソースをできるだけ早く発見できるようにする方法。
• Resource Load Duration: ファイル圧縮、最新のフォーマット、CDN構成、ネットワーク最適化を通じて、LCPリソースのダウンロード時間を短縮する方法。
• Element Render Delay: クリティカルCSS、JavaScriptの遅延、content-visibilityをカバーし、ダウンロード後すぐにLCP要素をペイントできるようにブラウザのメインスレッドをクリアする方法。