debug-optimize-lcp

LCP とは何か、なぜ重要なのか

Largest Contentful Paint（LCP）は、ページのメインコンテンツがどれだけ速く表示されるかを測定します。ナビゲーション開始から、ビューポート内で最大の画像またはテキストブロックが描画されるまでの時間です。

• 良好：2.5 秒以下
• 改善が必要：2.5～4.0 秒
• 不良：4.0 秒超

LCP は、ユーザー体験と検索順位に直接影響する Core Web Vital です。モバイルページの 73% では、LCP 要素は画像です。

LCP の内訳

各ページの LCP は、隙間や重複のない 4 つの連続した内訳に分けられます。どの内訳がボトルネックかを把握することが、効果的な最適化の鍵です。

内訳	LCP に占める理想的な割合	測定内容
Time to First Byte（TTFB）	~40%	ナビゲーション開始 → HTML の最初のバイトを受信
リソース読み込み遅延	<10%	TTFB → ブラウザーが LCP リソースの読み込みを開始
リソース読み込み時間	~40%	LCP リソースのダウンロードにかかる時間
要素の描画遅延	<10%	LCP リソースのダウンロード完了 → LCP 要素の描画

「遅延」にあたる内訳は、できるだけゼロに近づける必要があります。どちらかの遅延が LCP 全体に対して大きい場合は、まずそこを最適化しましょう。

よくある落とし穴：ほかの内訳を確認せずに、1 つの内訳（画像を圧縮して読み込み時間を短縮するなど）だけを最適化することです。本当のボトルネックが描画遅延の場合、画像を小さくしても効果はありません。短縮できた時間は、そのまま描画遅延に移るだけです。

デバッグのワークフロー

次の手順を順番に実行してください。各手順は前の手順を踏まえて進めます。

手順 1：パフォーマンストレースを記録する

ページに移動し、リロードを含むトレースを記録して、LCP を含めたページ読み込み全体を取得します。

1. navigate_page に pageId を指定し、対象の URL に移動します。
2. performance_start_trace に pageId、reload: true、autoStop: true を指定します。

トレース結果には、LCP のタイミングと利用可能なインサイトセットが含まれます。出力にあるインサイトセット ID をメモしてください。次の手順で使用します。

手順 2：LCP のインサイトを分析する

performance_analyze_insight を使用して、LCP に関するインサイトを詳しく調べます。トレース結果で次のインサイト名を探してください。

• LCPBreakdown — 4 つの LCP 内訳と、それぞれのタイミングを表示します。
• DocumentLatency — TTFB に影響するサーバー応答時間の問題です。
• RenderBlocking — LCP 要素の描画を妨げるリソースです。
• LCPDiscovery — LCP リソースを早期に検出できたかどうかを示します。

トレース結果にある pageId、インサイトセット ID、インサイト名を指定して performance_analyze_insight を呼び出します。

手順 3：LCP 要素を特定する

evaluate_script（pageId を指定）と、references/lcp-snippets.md にある 「Identify LCP Element」スニペットを使用して、LCP 要素のタグ、リソース URL、生のタイミングデータを確認します。

url フィールドから、ネットワークウォーターフォールで確認するリソースがわかります。url が空の場合、LCP 要素はテキストベースであり、読み込むリソースはありません。

手順 4：ネットワークウォーターフォールを確認する

list_network_requests を使用して、ほかのリソースと比べて LCP リソースがいつ読み込まれたかを確認します。

• list_network_requests に pageId を指定し、resourceTypes: ["image", "font"] で絞り込みます（手順 3 に応じて調整してください）。
• 次に get_network_request に pageId と LCP リソースのリクエスト ID を指定して、詳細を取得します。

主な確認項目：

• 開始時間：HTML ドキュメントおよび最初のリソースと比較します。LCP リソースの読み込み開始が最初のリソースより大幅に遅い場合、解消すべきリソース読み込み遅延があります。
• 読み込み時間：リソース読み込み時間が長い場合、ファイルが大きすぎるか、サーバーの応答が遅い可能性があります。

ステップ 5: よくある問題について HTML を検査する

evaluate_script（pageId を指定）と、references/lcp-snippets.md にある 「Audit Common Issues」スニペット を使用して、ビューポート内の遅延読み込み画像、fetchpriority の欠落、レンダリングをブロックするスクリプトをチェックします。

最適化戦略

ボトルネックとなっているサブパートを特定したら、これらの優先順位付けされた修正を適用します。

1. リソースの読み込み遅延を解消する（目標: 10% 未満）

最もよくあるボトルネックです。LCP リソースは即座に読み込みを開始する必要があります。

• 根本原因: LCP 画像が JS/CSS 経由で読み込まれている、data-src の使用、または loading="lazy"。
• 修正: 標準の <img> と src を使用します。LCP 画像を絶対に遅延読み込みしないでください。
• 修正: 画像が HTML 内で検出可能でない場合は、<link rel="preload" fetchpriority="high"> を追加します。
• 修正: LCP の <img> タグに fetchpriority="high" を追加します。

2. 要素のレンダリング遅延を解消する（目標: 10% 未満）

要素は読み込み直後にレンダリングされる必要があります。

• 根本原因: 大きなスタイルシート、<head> 内の同期スクリプト、またはメインスレッドのブロック。
• 修正: クリティカル CSS をインライン化し、非クリティカルな CSS/JS を遅延させます。
• 修正: メインスレッドをブロックしている長いタスクを分割します。
• 修正: サーバーサイドレンダリング（SSR）を使用して、要素が初期 HTML に存在するようにします。

3. リソースの読み込み時間を短縮する（目標: 約 40%）

リソースをより小さく、またはより速く配信できるようにします。

• 修正: モダンなフォーマット（WebP、AVIF）とレスポンシブ画像（srcset）を使用します。
• 修正: CDN から配信します。
• 修正: Cache-Control ヘッダーを設定します。
• 修正: LCP が Web フォントによってブロックされるテキストの場合は、font-display: swap を使用します。

4. TTFB を削減する（目標: 約 40%）

HTML ドキュメント自体の到着に時間がかかりすぎています。

• 修正: リダイレクトを最小限にし、サーバーの応答時間を最適化します。
• 修正: エッジ（CDN）で HTML をキャッシュします。
• 修正: ページが戻る/進むキャッシュ（bfcache）の対象となるようにします。

修正の検証とエミュレーション

• 検証: トレースを再実行し（performance_start_trace に pageId と reload: true を指定）、新しいサブパートの内訳を比較します。ボトルネックが縮小しているはずです。
• エミュレーション: ラボでの測定値は実環境の体験とは異なります。emulate を使用して制約下でテストします:
  • emulate に pageId、networkConditions: "Fast 3G"、cpuThrottlingRate: 4 を指定します。
  • これにより、低速な接続やデバイスでのみ見られる問題が明らかになります。