✍️

Cursor + ChromeDevTools MCP パフォーマンス計測

2025/10/19に公開

Chrome

Model Context Protocol

Cursor

tech

経緯

ChromeDevTools MCPを使ってパフォーマンス計測の自動化ができる。
ということを見聞きしたので、試してみる。

セットアップ

CursorでChromeDevTools MCPを使えるようしていきます。

ChromeDevTools MCPを利用したいプロジェクトのルートディレクトリに.cursor/mcp.jsonファイルを作成。
※グローバルに設定したい方(Macユーザ)は/Users/username/.cursor/mcp.jsonに設置
※usernameはご自身のPCのユーザ名に置き換えてください
次のコードを貼り付ける

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest"]
    }
  }
}

公式Github

Cursor → Preference → Cursor Settings→ Tools & MCPを確認して緑色のバッジがついていたら準備OK！

※赤色のバッジがついていたら以下の記事を参考にしてみてください。

動作確認

次の公式サイトに動作確認用のプロンプトが用意されているので入力して動作確認をします。

プロンプト

Check the performance of https://developers.chrome.com

※Agentモードで実行しました

アウトプット

I ran a throttled performance trace (Fast 4G, 4x CPU) with reload and analyzed the page’s insights.

Core results
LCP: 1.25s (text; no LCP resource) — TTFB 523ms, render delay 723ms
CLS: 0.03 (good)
Field data: none (no CrUX for this page)

Notable findings
Render‑blocking CSS (est. save ~275ms FCP/LCP):
Google Fonts CSS (multiple)
DevSite app.css
extras.css
Third‑party impact:
Transfer size: Google CDN ~2.8MB, Google Fonts ~1.7MB, GTM ~726kB
Main‑thread time: Google CDN ~325ms, GTM ~193ms
CLS culprits: unsized images (logo, SVGs) causing minor shifts
Other flags: large DOM, forced reflows observed

Quick wins
Inline critical CSS; defer or split non‑critical CSS; consider media + onload swap
Fonts: add font-display: swap/optional; consider font metric overrides; preconnect to fonts.gstatic.com
Audit and defer third‑party tags (especially GTM); load non‑essential scripts after LCP
Always set explicit width/height on images (incl. logo/SVG); lazy‑load below‑the‑fold
Reduce DOM complexity where possible; avoid forced reflows by batching reads/writes
LCP and CLS are solid under throttling; most he![](https://storage.googleapis.com/zenn-user-upload/952fe197e7bd-20251019.png)adroom is in render‑blocking CSS and third‑party weight/execution.

Chromeで実際にCPUやNetworkの条件を一致させてPerformanceタブからLCP, CLSの数値を確認するとほとんど一致していることが確認できたので、正しく利用できていそうです👀
Cursorの出力

LCP: 1.25s
CLS: 0.03

セルフ確認結果

LCP: 1.31s
CLS: 0.02

開発環境（localhost:XXXX）での動作確認

こちらの記事で利用した画面で動作確認を行います。

上記記事ではlighthouseの測定値と課題は次のような結果でした。
計測結果

FCP: 1.0 s
LCP: 5.3 s
TBT: 0 ms
CLS: 0

課題

HERO画像のサイズが大きくLCPに大きく影響が出ている

同じような測定値と課題が出ることを狙ってプロンプトを作ります。

プロンプト

以下の情報を出力してください
- lighthouseの計測結果
- lighthouseの計測結果をもとにした改善点

計測するページ
- localhost:3000/login

開発環境の立ち上げ方
- npm run build
- npm run start

アウトプット
概ね狙った結果が出ました。
※他にも細かい改善点や計測結果が出ましたが、必要な情報だけ抜粋します。

計測結果 (localhost:3000/renewal/user/login)
FCP: 1.2 s
LCP: 5.2 s
TBT: 50 ms
CLS: 0

改善ポイント（特にモバイルのLCP 5.2sがボトルネック）
画像の優先制御
- LCP要素の画像をプレロード: <link rel="preload" as="image" href="...">
- LCP画像は遅延読み込みしない（fold内は loading="eager"）
- 画像サイズの最適化と明示的な width/height 付与

※開発環境の立ち上げはcursorに行ってもらう必要があるため、ターミナル等でlocalhostが立ち上がっている場合は閉じるようにしてください。（または、異なるポート番号を指定して立ち上げるなど工夫が必要になると思います）

開発環境でも同様にパフォーマンスに計測をすることができました🙌🏻

利用可能な操作一覧

まとめ

Chrome Devtools MCPがcursorで有効化?されていない状態で計測できていた時もあったので、正しく使えているかは不安が残りますが、cursorの出力結果が手動で計測時とほぼ一致していたので一旦は正しくできていると仮定して使っていきたいと思います💦

今後は、

計測後の値を利用してパフォーマンス改善までを自動化するプロンプトを組む
計測結果をファイルとして出力して改善の記録を履歴として残す
AIを利用したパフォーマンス改善方法をマニュアル化
などに利用してみるのが良いのかな?と..思いました。🫤

経緯

セットアップ

動作確認

開発環境（localhost:XXXX）での動作確認

利用可能な操作一覧

まとめ

Discussion