Anthropic Claudeソフトウェア開発⭐ リポ 0品質スコア 50/100

debug-optimize-lcp

Name: debug-optimize-lcp
Author: chromedevtools

LCP（Largest Contentful Paint）のデバッグと最適化を、Chrome DevTools の MCP ツールを使ってガイドするスキルです。ユーザーが LCP のパフォーマンス改善、ページの読み込み速度、Core Web Vitals の最適化について質問したり、ヒーロー画像やメインコンテンツの表示が遅い原因を調べたいときに活用してください。「largest contentful paint」「page load speed」「CWV」といったキーワードが挙がった場合にも適用されます。

description の原文を見る

Guides debugging and optimizing Largest Contentful Paint (LCP) using Chrome DevTools MCP tools. Use this skill whenever the user asks about LCP performance, slow page loads, Core Web Vitals optimization, or wants to understand why their page's main content takes too long to appear. Also use when the user mentions "largest contentful paint", "page load speed", "CWV", or wants to improve how fast their hero image or main content renders.

SKILL.md 本文

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 の最初のバイト受信
Resource load delay	10% 未満	TTFB → ブラウザが LCP リソースの読み込み開始
Resource load duration	約 40%	LCP リソースのダウンロード時間
Element render delay	10% 未満	LCP リソースダウンロード → LCP 要素レンダリング

「遅延」サブパーツはできるだけゼロに近い必要があります。どちらかの遅延サブパーツが LCP 全体に対して大きい場合、そこが最初の最適化対象です。

よくある落とし穴: 他の部分をチェックせずに 1 つのサブパーツ（例えば、読み込み時間を減らすための画像圧縮）のみを最適化する。レンダリング遅延が実際のボトルネックの場合、より小さい画像は役に立たず、短縮された時間がレンダリング遅延にシフトするだけです。

デバッグワークフロー

以下のステップを順番に実行します。各ステップは前のステップの上に構築されます。

ステップ 1: パフォーマンストレースを記録

ページに移動してから、LCP を含む完全なページロードをキャプチャするためにリロード付きのトレースを記録します。

navigate_page でターゲット URL に移動
performance_start_trace を reload: true および autoStop: true で実行

トレース結果には LCP タイミングと利用可能なインサイトセットが含まれます。出力からインサイトセット ID をメモしておきます。次のステップで必要になります。

ステップ 2: LCP インサイトを分析

performance_analyze_insight を使用して LCP 固有のインサイトを詳しく調べます。トレース結果で以下のインサイト名を探してください。

LCPBreakdown — 4 つの LCP サブパーツと各部のタイミングを表示
DocumentLatency — TTFB に影響するサーバーレスポンス時間の問題
RenderBlocking — LCP 要素のレンダリングをブロックしているリソース
LCPDiscovery — LCP リソースが早期に検出可能だったかどうか

トレース結果からインサイトセット ID とインサイト名を指定して performance_analyze_insight を呼び出します。

ステップ 3: LCP 要素を特定

references/lcp-snippets.md にある 「LCP 要素を特定」スニペット を使用して evaluate_script を実行し、LCP 要素のタグ、リソース URL、および生のタイミングデータを明らかにします。

url フィールドは、ネットワークウォーターフォール内で探すリソースを示します。url が空の場合、LCP 要素はテキストベース（読み込むリソースなし）です。

ステップ 4: ネットワークウォーターフォールを確認

list_network_requests を使用して、LCP リソースが他のリソースに相対して読み込まれたときを確認します。

list_network_requests を resourceTypes: ["Image", "Font"] でフィルタリングして呼び出し（ステップ 3 に基づいて調整）
get_network_request を LCP リソースのリクエスト ID で呼び出して完全な詳細情報を取得

主要なチェック項目:

開始時刻: HTML ドキュメントと最初のリソースと比較。LCP リソースが最初のリソースよりもはるかに遅く開始する場合、排除すべきリソース読み込み遅延があります。
期間: リソース読み込み時間が長い場合、ファイルが大きすぎるか、サーバーが遅い可能性があります。

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

references/lcp-snippets.md にある 「よくある問題を監査」スニペット を使用して evaluate_script を実行し、ビューポート内の遅延読み込み画像、欠落した 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 ドキュメント自体の到着に時間がかかっています。

修正: リダイレクトを最小化し、サーバーレスポンス時間を最適化。
修正: HTML をエッジ（CDN）でキャッシュ。
修正: ページが戻る/進むキャッシュ（bfcache）の対象になることを確認。

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

検証: トレースを再実行（performance_start_trace を reload: true で実行）し、新しいサブパーツの内訳と比較。ボトルネックが縮小するはずです。
エミュレーション: ラボの測定値は実際の体験と異なります。制約下でテストするために emulate を使用。
- emulate を networkConditions: "Fast 3G" および cpuThrottlingRate: 4 で実行。
- これにより、遅いネットワーク/デバイスでのみ表示される問題が浮き彫りになります。

ライセンス: Apache-2.0(寛容ライセンスのため全文を引用しています) · 原本リポジトリ

詳細情報

作者: chromedevtools
リポジトリ: chromedevtools/chrome-devtools-mcp
ライセンス: Apache-2.0
最終更新: 不明

GitHubで原本を見る →フィードバックを送る

Source: https://github.com/chromedevtools/chrome-devtools-mcp / ライセンス: Apache-2.0