Largest Contentful Paint (LCP) の問題の特定と修正

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

LCPの診断と修正ガイド

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

LCPの改善は消去法です。2025 Web Almanacによると、LCPの基準を満たしているモバイルのオリジンはわずか66%です。つまり、ウェブの3分の1が読み込みの問題を抱えています。最も遅いフェーズを見つけ、修正し、再度測定してください。

診断手法：field dataを先に、lab dataを後に

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

1. field data (RUMおよびCrUX) は、何が起きているかを示します。 field dataは、サイトを訪れる実際のユーザーから収集されます。これにより、LCPの問題があるか、どのページが影響を受けているか、そしてどのユーザー（モバイルかデスクトップか）がそれを経験しているかが分かります。実際の問題が存在することを確認するために、必ずここから始めてください。
2. lab data (Lighthouse、DevTools) は、なぜそれが起きているかを診断するのに役立ちます。 lab dataは、制御されたシミュレーション環境で収集されます。field dataで特定のページに問題があることを確認したら、ラボツールを使用して問題を継続的に再現し、読み込みプロセスを分析して根本原因を特定できます。

実際のユーザーに影響を与える変更を最適化のターゲットにするために、field dataから始めてください。

ステップ1: field dataでLCPの問題を特定する

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

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

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

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

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

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

私はまさにこのためにCoreDashを構築しました。scriptタグを1つ追加するだけで、すべての実際の訪問者からLCPデータを収集し、ページ、デバイス、要素ごとに分類します。

優れたRUMツールでは以下を確認できます。

• 特定のURLの正確なLCPスコア。
• 各LCP要素（画像、見出しなど）の内訳と、どれが遅いLCPと最も頻繁に関連しているか。
• すべてのページビューにおける4つのLCPフェーズそれぞれの正確なタイミング。これによりボトルネックを特定します。

LCP要素そのもの以外にも目を向けることが重要です。詳細なケーススタディでは、VodafoneがLCPを31%改善し、それが売上の8%増加に直接貢献しました。彼らの最適化は、field data分析と的を絞った修正を組み合わせて、主要なランディングページの特定のLCPボトルネックを特定し解決することに重点を置いていました。LCP最適化は画像だけではありません。サーバーのレスポンス、リソースの検出、ダウンロード、ペイントなど、読み込みパイプライン全体を理解する必要があります。

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

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

Performance Observer APIによるLCPの測定

Performance Observer APIを使用すると、JavaScriptでLCPエントリに直接アクセスできます。これは、RUMツールがfield dataを収集するために内部で使用しているのと同じ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ライブラリを使用してください。これにより、タブの表示/非表示の切り替えやback/forwardキャッシュの復元などのエッジケースが処理されます。

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

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

レポートの「Diagnostics」セクションまでスクロールし、「Largest Contentful Paint element」監査を見つけます。このウォーターフォールチャートは、LCP時間を4つのサブパートに分解します。RUMツールでも、field dataに基づいた同様の内訳が表示されるはずです。

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

ステップバイステップガイド: DevToolsでの作業を好みますか？Chrome DevTools PerformanceパネルによるLCPの診断では、スロットリングされたトレースを記録し、LCP内訳のインサイトから同じ4つのサブパートを読み取る方法を説明しています。

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

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

• Time to First Byte (TTFB): これはスキップできない基盤です。サーバーのレスポンスが遅いと、1ミリ秒単位で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の画像ファイルが完全にダウンロードされていても、ブラウザのmain threadが重いJavaScriptの実行によってブロックされていると、画面への画像のペイントに取り掛かることができません。Element Render Delayの完全なガイドをお読みください。

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

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

ボトルネックが特定できたら、修正を適用します。実装はスタックに依存します。以下の各フェーズでは、まず普遍的な原則を取り上げ、次にWordPressとJSフレームワークの特記事項をカバーします。

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

TTFBが遅い場合（良い目標は800ms未満です）、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ステータスコードを使用します。これにより、サーバーまたはCDNが完全なHTMLドキュメントを準備している間に、重要なCSSやJSファイルに関するヒントをブラウザに送信でき、ダウンロードをさらに早く開始できます。完全な実装ガイドについては、103 Early Hintsの記事を参照してください。

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

WordPressの場合:

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

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

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

2. Resource Load Delayの削減

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

普遍的なLoad Delayの解決策

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

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

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

WordPressの場合:

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

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

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

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サイズを生成できます。
• 手動での画像のリサイズ: アップロードする前に、画像を必要なサイズ以下にリサイズしてください。最大の画面でも1200ピクセル幅しかないスペースに、4000ピクセル幅の画像をアップロードしないでください。

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

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

4. Element Render Delayの短縮

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

普遍的なRender Delayの解決策

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

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

WordPressの場合:

• プラグインの監査: プラグインが多すぎると、特にスライダーや複雑なページビルダーなどの重いものは、main threadをブロックする大量のCSSやJSを追加する可能性があります。プラグインを1つずつ無効にして、パフォーマンスを低下させているものを特定してください。
• 軽量なテーマの使用: 使用しない機能が多数ある肥大化したテーマは、render blockingコードの大きな原因になる可能性があります。パフォーマンスに焦点を当てたテーマを選んでください。
• プラグインアセットマネージャーの使用: Asset CleanUpやPerfmattersなどのツールを使用すると、不要なページで特定のプラグインからのCSSやJSを条件付きで無効にすることができます。

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

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

高度なトピック: 後続のナビゲーションに向けたLCPの最適化

初期のLCPを修正することは重要ですが、後続のページ読み込みを最適化することで、サイトの閲覧を瞬時に感じさせることができます。

ページがBack/Forward キャッシュ (bfcache) の対象であることを確認する

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

プリレンダリングにSpeculation Rules APIを使用する

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

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

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

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

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

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

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