Chrome DevTools MCPでLCPが遅い原因を絞って直す手順

LCPが遅いページの原因は、Chrome DevTools MCPのperformance_analyze_insightで「どの区間に時間がかかっているか」まで絞れます。流れは、トレースを採る、インサイトで内訳を見る、1か所だけ直す、同じ条件でもう一度採る、の4段です。

LCP(Largest Contentful Paint)は、ビューポート内で最大の画像・テキストブロック・動画が描画されるまでの時間です。ページに最初に遷移した時点からの経過で測り、良好とされる目安は75パーセンタイルで2.5秒以下です。

導入手順はすでにChrome DevTools MCPの導入ガイドにあります。ここでは導入済みの環境で、LCPだけに絞って原因を潰す手順を扱います。

3つのツールの役割を押さえる

計測に使うのはperformance_start_trace、performance_stop_trace、performance_analyze_insightの3つです。ツールリファレンスでは、この3つが「Performance」カテゴリにまとまっています。

performance_analyze_insightのinsightNameは、リファレンスの例でDocumentLatencyとLCPBreakdownが挙がっています。insightSetIdには、トレース結果の「Available insight sets」に出たIDだけを使います。自分で作ったIDは渡せません。

計測の条件を先に固定する

LCPは、同じページでも回線とCPUの条件で大きく変わります。直す前後を比べるなら、条件を固定してから採ります。

条件はemulateで決めます。1回の呼び出しで、extraHttpHeadersを除くすべてのエミュレーション設定が置き換わるため、必要な設定は1回にまとめて渡します。

トレースの記録は次の順で進めます。

filePathを渡すと、生のトレースをファイルに保存できます。直す前はbefore.json.gz、直した後はafter.json.gzのように名前を分けておくと、後から見比べられます。

Claude Codeに頼むときは、手順をそのまま文にします。例えば次のような依頼です。

http://localhost:3000/ を、375x667x2のmobile・Slow 4G・CPU 4倍低下で計測して。
reload と ignoreCache を有効にして before.json.gz に保存し、
LCPのインサイトを performance_analyze_insight で詳しく見て。
重い区間が1つに絞れるところまで説明して。

LCPを4つの区間に分けて、重い区間を探す

LCPBreakdownという名前のインサイトを見る前に、LCPがどんな区間でできているかを知っておくと、返ってきた内訳を読みやすくなります。web.devは、LCPを4つの区間に分けて最適化するよう勧めています。

4つの区間は重ならず、隙間もなく、合計がLCPの全体になります。LCP要素が画像などの読み込みを要さないテキストなら、2つ目と3つ目は0です。

名前に「delay」が付く2区間は、ゼロに近いほどよい区間です。残る2つはネットワークを使うので、時間がかかること自体は避けられません。したがって、重い区間を探すときは、まずdelayが大きすぎないかを見ます。

LCPBreakdownが実際にどの項目をどんな形で返すかは、ツールリファレンスに書かれていません。返ってきた内訳が上の4区間のどれに当たるかは、結果を読んで対応づけます。

区間ごとに直す手を決める

重い区間が分かったら、その区間に効く直し方を選びます。区間と直し方の対応は、web.devの最適化ガイドに沿ったものです。

TTFB区間が重いときは、ブラウザ側の最適化ではほとんど動きません。web.devは、TTFBが高くなる原因として、複数回のサーバーリダイレクト、最寄りのサーバーから遠い訪問者、回線の悪い環境、クエリパラメータのせいでキャッシュを使えないこと、を挙げています。画像やスクリプトを直す前に、この区間が全体の約40%を占めていないかを見ておくと、遠回りを避けられます。

ツールリファレンスの例にあるDocumentLatencyは、この区間を調べるときに最初に指定するインサイトの候補です。名前からはHTMLドキュメントの応答に関するインサイトと読めますが、返す項目はリファレンスに書かれていないため、実際に呼んで返りを確かめます。

LCP画像に付けるfetchpriority="high"は、LCPになりそうな<img>に付けるとよいとされています。ただし、高優先度を付ける画像が1〜2枚を超えると、優先度の指定が意味を持たなくなります。

Resource load durationは、画像を軽くするだけでなく、配信元を利用者に近づけても縮みます。web.devは、サーバーを地理的に近づけるいちばんよい方法としてCDNを挙げ、画像CDNなら距離と画像サイズの両方を減らせると説明しています。ただし画像だけ別ドメインに置くと接続を張り直す分のコストが増えるため、HTMLと同じオリジンから配信できる構成が望ましいとされています。

Resource load delayは、LCP画像の読み込み開始がほかのリソースより遅れていないかで見分けられます。ページ内で最初に読み込まれるリソースと同時に始まっていれば、多くのページで十分です。

1か所を直すと、時間が別の区間に移ることがある

web.devは、ある区間を縮めてもLCPが縮まらない例を挙げています。画像を圧縮して読み込み時間を縮めても、LCP要素がJavaScriptの読み込み完了まで隠れているページでは、浮いた時間がElement render delayにそのまま移るだけです。

この例が示すのは、区間を1つ直して終わりにしないことです。直したら再計測して、内訳の別の区間が増えていないかを見ます。

同じ条件で再計測して、前後を比べる

直したら、計測の条件も手順も変えずにもう一度トレースを採ります。変えてよいのは、直した箇所だけです。

さっきと同じ条件(375x667x2のmobile・Slow 4G・CPU 4倍低下)で、
同じURLを reload と ignoreCache 付きで再計測して after.json.gz に保存して。
before の LCP と、重かった区間が何ms から何ms になったかを並べて。
他の区間が増えていたら、それも教えて。

見るのは、LCPの合計が2.5秒以下に入ったか、直した区間が縮んだか、ほかの区間が増えていないか、の3点です。合計が縮まず、直した区間だけが縮んでいたら、時間が隣の区間へ移った可能性があります。上の「時間が別の区間に移る」例に当たるかを確かめます。

毎回同じ手順で回すために、CLAUDE.mdに書いておく

条件の指定を毎回口頭で伝えると、前後で条件がずれる原因になります。計測の条件と順序は、プロジェクトのCLAUDE.mdに固定しておくと、Claudeが毎回同じ手順で回します。

## LCP計測のルール
 
- 計測は Chrome DevTools MCP で行う
- 条件は emulate で viewport=375x667x2,mobile,touch / networkConditions=Slow 4G / cpuThrottlingRate=4 に固定する
- performance_start_trace は reload=true, ignoreCache=true で呼ぶ
- insightSetId は stop_trace の結果の「Available insight sets」にあるIDだけを使う
- 直す前後でトレースを before.json.gz / after.json.gz に保存し、LCPと4区間を並べて報告する
- 1回の修正で直すのは1区間だけ。直した後は他の区間が増えていないかを必ず確認する

ツールの呼び出しを毎回確認されたくないときは、.claude/settings.jsonのpermissions.allowにMCPツールを列挙します。MCPツール名はmcp__<サーバー名>__<ツール名>の形で、サーバー名をchrome-devtoolsとして追加した場合は次のようになります。

{
  "permissions": {
    "allow": [
      "mcp__chrome-devtools__performance_start_trace",
      "mcp__chrome-devtools__performance_stop_trace",
      "mcp__chrome-devtools__performance_analyze_insight"
    ]
  }
}

トレース採取の3つだけを許可し、evaluate_scriptのようなページ内でコードを実行するツールは対象外にしておく構成です。

よくあるつまずき

手元のLCPと、実ユーザーのLCPがずれる

web.devは、LCPが前のページのアンロード時間・接続の確立・リダイレクト・TTFBの遅れを含むと説明しています。これらはフィールド(実ユーザー)で測ると大きく出る場合があり、ラボとフィールドで値が食い違う原因になります。手元のトレースは、原因を絞るための材料と位置づけるのが現実的です。

なお、パフォーマンス系のツールは、トレースのURLをGoogleのCrUX APIに送って実ユーザーのデータを取得することがあります。これを止めるには、起動時に--no-performance-cruxを付けます。

performance_analyze_insightが動かない

insightSetIdは、トレース結果の「Available insight sets」にあるIDだけが使えます。トレースを採る前や、IDを拾わずに呼ぶと渡せる値がありません。先にperformance_stop_traceまで済ませ、結果からIDを引きます。

リロードのたびに別のページが計測される

reloadやautoStopを使う場合は、navigate_pageで正しいURLへ移ってからトレースを始めます。遷移の前に始めると、意図しないページを計測します。

Lighthouseのパフォーマンススコアが出ない

lighthouse_auditはパフォーマンスを含みません。アクセシビリティ・SEO・ベストプラクティス・エージェント向けブラウジングのスコアを返すツールで、性能はperformance_start_traceで見る分担です。CIで回帰を防ぐなら、Lighthouse CIをHooksで自動実行する手順の領分になります。

まとめ

LCP改善の核は、1回の修正で1つの区間だけを動かし、前後を同じ条件で測ることです。performance_analyze_insightは、その1区間を特定する道具として働きます。

計測の条件と手順をCLAUDE.mdに書いておけば、誰が頼んでも同じ前後比較になります。表示速度を詰めた実例は、claude.aiの高速化の2週間でも読めます。