Chrome DevTools MCP 教學：讓 AI 量網頁速度、跑 Lighthouse，拿我的網站實測

網頁改完覺得變慢了、某個按鈕點下去沒反應，以前的做法是自己打開瀏覽器的開發者工具，看網路請求、看錯誤訊息、錄一段效能紀錄，再把看到的東西貼給 AI 問。

Chrome DevTools MCP 把這幾步交給 AI 自己做。它是 Chrome 開發者工具團隊做的 MCP 伺服器，接上之後，Claude Code、Cursor 這類工具可以自己開網頁、錄效能、跑 Lighthouse、看網路和錯誤訊息，再根據結果建議怎麼改。

這篇講它是什麼、跟 Playwright MCP 差在哪、怎麼加、預設會送哪些資料，然後拿這個網站的首頁實際量一次。MCP 本身是什麼，在 MCP 是什麼。

它是什麼

官方 README 現在把它叫「Chrome DevTools for agents」，套件名稱還是 chrome-devtools-mcp。它控制的是一個真的 Chrome，底下用的是 Puppeteer 這套自動化工具。

官方列的三個重點：

• 效能：錄效能追蹤（trace），整理出可以動手改的建議。
• 除錯：看網路請求、截圖、看 console 的訊息。
• 自動化：點、填表、等待結果，會自動等動作完成。

我實測的 1.10.1 版一共 30 個工具，分成輸入、導航、模擬、效能、網路、除錯、記憶體、擴充功能幾類。其中一個是 lighthouse_audit，直接在 AI 的對話裡跑 Lighthouse。

跟 Playwright MCP 差在哪

兩個都能讓 AI 開瀏覽器、點東西、截圖。差別在重點：Chrome DevTools MCP 多了開發者工具那一面，效能追蹤、Lighthouse、網路和 console、記憶體快照；Playwright MCP 偏向自動化操作，而且支援多種瀏覽器。

我的分法是：要找網頁為什麼慢、哪裡在報錯，用 Chrome DevTools MCP；要讓 AI 在網站上點來點去完成一件事，用 Playwright MCP。

怎麼裝

需要 Node.js（LTS 版）和 Chrome。官方寫的是 Chrome 目前的穩定版或更新，而且只正式支援 Google Chrome 和 Chrome for Testing。

Claude Code 用官方文件給的這一行，加在使用者層級，每個專案都能用：

claude mcp add chrome-devtools \
  --scope user \
  npx chrome-devtools-mcp@latest

官方也提供外掛的裝法，會一起裝它的 Skills：在 Claude Code 裡先加它的外掛市集 /plugin marketplace add ChromeDevTools/chrome-devtools-mcp，再安裝外掛。官方提醒，用過 MCP 的方式裝的人，要先把舊的拿掉。

其他工具用的是同一段設定：

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

幾個常用的選項：

• --headless：不開視窗。
• --isolated：用暫時的瀏覽器資料，關掉就清掉。
• --slim：只留 3 個工具（開網頁、執行腳本、截圖），簡單的工作用這個就好，比較省。

瀏覽器不會一連上就打開，要等 AI 第一次用到需要瀏覽器的工具才會啟動。官方建議的第一句測試是：「Check the performance of https://developers.chrome.com」。

預設會送出的資料

這一段值得先知道。官方 README 寫了兩件事：

• 預設會收集使用統計，例如工具呼叫的成功率、延遲和環境資訊。要關掉，加 --no-usage-statistics。
• 效能工具可能會把你量的網址送到 Google 的 CrUX API，拿真實使用者的效能資料一起比較。要關掉，加 --no-performance-crux。

另外它會定期檢查 npm 上有沒有新版。官方也提醒，它會把瀏覽器裡的內容開放給 AI 檢查和修改，不要讓它碰你不想分享的資料。

我實測時兩個資料都關了。

實測：量這個網站的首頁

我在雲端測試機上裝了 Google 官方的 Chrome 穩定版（安裝檔 144 MB，連同相依套件裝了 28 秒，版本 155），用 MCP 官方的 SDK 啟動 Chrome DevTools MCP，直接呼叫它的工具，不經過 AI。從開網頁到截圖，一整串 13 秒。

頁面結構

它也有讀頁面結構的工具，首頁是 1 萬 4 千多個字元。格式跟 Playwright 的不一樣，每個元素前面是 uid：

uid=1_3 banner
  uid=1_4 link "Carl 的說人話研究室 首頁"
    uid=1_5 StaticText "Carl 的說人話研究室"
  uid=1_6 navigation "主選單"
    uid=1_7 link "OpenClaw 龍蝦"

（我把網址那一欄拿掉了。）

效能追蹤

performance_start_trace 會重新載入頁面、錄一段追蹤，5.7 秒後回來一份摘要：

• LCP（最大的內容畫出來的時間）：232 毫秒。其中伺服器回應 41 毫秒，畫面渲染的延遲 191 毫秒。
• CLS（版面跳動）：0。

要說明一下：這次沒有模擬慢速的手機和網路，摘要裡寫著 CPU 和網路都沒有降速，所以是在一台快的機器上量的結果，實際用手機開會慢一些。真實使用者的資料那一欄是「沒有資料」。

摘要後面列了五個可以再深入的建議，例如 LCP 的組成、關鍵請求的串接、第三方程式碼、快取時間、舊式的 JavaScript（估計多了 10.6 KB）。AI 可以再用 performance_analyze_insight 展開其中一個問細節。

Lighthouse

lighthouse_audit 用手機模式跑，5.2 秒：

• 無障礙（Accessibility）：100
• 最佳做法（Best Practices）：100
• SEO：100
• Agentic Browsing：100

這個工具不含效能分數，官方說效能要用上面的效能追蹤。Agentic Browsing 是我第一次在 Lighthouse 裡看到的分類，從名稱看是評估網頁給 AI 代理用的狀況。

四項都是 100，但總共 49 項通過、1 項沒過。我打開它存下來的報告看，沒過的是 label-content-name-mismatch：頁首左上角的站名連結，我給它設了一個 aria-label（給螢幕閱讀器讀的名稱）叫「Carl 的說人話研究室 首頁」，但畫面上的字還包含一個「話」字的印章圖示，兩邊對不上。Lighthouse 的說明是，看得到的文字跟無障礙名稱不一致，會讓用螢幕閱讀器的人困惑。

這一項沒過，無障礙的分數還是 100，看起來它沒有算進分數裡。但問題是真的，而且很好修：我把那個 aria-label 拿掉，讓連結的名稱直接用畫面上的站名，當天就部署了。

網路和 console

首頁一共 8 個請求：頁面本身、3 個字型檔、網站圖示，以及 Cloudflare 自動加上的幾個請求（流量統計的腳本和回報、預先載入的規則）。console 沒有任何錯誤訊息。截圖 0.1 秒就回來了。

這些結果原本要自己打開開發者工具一頁一頁看，現在 AI 一次拿到，可以直接接著問「LCP 怎麼再降」「這個第三方腳本可以延後載入嗎」。

用之前要知道的

它看得到瀏覽器裡的所有東西。用自己平常的 Chrome 資料的話，登入狀態、Cookie 都在裡面。不需要的時候加 --isolated。

預設的資料傳送，上面講過：使用統計和 CrUX。介意就關掉。

效能數字要看條件。沒有模擬慢速手機和網路的話，量出來會比真實使用者快很多。

工具多，說明也長。30 個工具的說明都會進到 AI 的對話裡；只需要開網頁和截圖的話，--slim 比較省。

這篇沒有測的

讓 Claude Code 實際連上去使用。這次是我直接呼叫工具，Claude Code 怎麼用 MCP 伺服器的過程，可以參考我在 Playwright MCP 教學和 Context7 是什麼裡的實測。

接上你自己已經開著的 Chrome（--autoConnect 等選項）、外掛加 Skills 的裝法、Android 除錯、記憶體快照。

在模擬手機和慢速網路的條件下量效能。