前端工程師：效能最佳化與 DevTools 除錯

這行的痛點

前端工程師的「效能最佳化」跟「除錯」表面上是兩件事——一個在拉 Lighthouse 分數，一個在抓 console 裡的紅字——但拆開來看，兩者其實是同一個能力的兩種應用：都需要先看到瀏覽器裡真實發生了什麼，而不是憑經驗猜。傳統流程是工程師自己開 DevTools 面板、盯著 waterfall 圖表、把 stack trace 複製貼進編輯器，來回切換視窗做「人工橋接」；Claude Code 透過 Chrome DevTools MCP 這類官方工具鏈，可以直接呼叫 performance_start_trace、list_network_requests 這些工具讀到第一手資料，省掉這段複製貼上的人工橋接。

這也是為什麼這一章把「效能最佳化」跟「DevTools 除錯」放進同一個工作面向：底層是同一套工具鏈。想把 Lighthouse 分數從 60 拉到 92，靠的是 Claude 讀懂效能追蹤檔案；想抓出 console 裡的 CORS 錯誤或一段看不懂的堆疊追蹤，靠的是同一套工具讀 network 標頭與錯誤堆疊。工程師學會一次「讓 Claude 看到瀏覽器真實狀態」的用法，兩種任務都能沿用，不用分別學兩套流程。

但這條路不是全自動就萬事大吉。下面四個案例特別挑了有具體數字、查得到出處的真實紀錄：兩個效能案例告訴你自動化迴圈能拉分數，但沒設護欄會出事；兩個除錯案例告訴你 Claude 能幫你看瀏覽器裡的真實狀態，但看到的東西怎麼判斷、要不要照單全收，仍然是工程師的責任——尤其 CORS 那個案例，直接點名 AI 慣性生成的不安全設定，正好呼應前面「不能照單全收」這句話。

動手前的準備

• 先確認所選 CLI 已能在本機啟動，Git 也能正常用來查看與還原專案變更。
• 用一個可安全測試的專案練習；不要拿唯一副本、正式資料或線上服務做第一次稽核與修復。
• 想同時對照 Codex CLI，先看 Codex CLI 教學第 1 章把安裝走完。
• 四個場景都仰賴同一套官方 MCP 工具鏈（chrome-devtools-mcp / lighthouse-mcp），建議先看 Claude Code 教學第 9 章「連接工具 MCP」搞懂 MCP 是什麼、怎麼裝，本章不重複講安裝機制。
• 若你選用 npm／npx 路徑，依所選工具的要求準備 Node.js；不是所有 CLI 安裝路徑都需要它。Chrome 則使用最新穩定版。
• 若要示範場景三、四的瀏覽器讀取能力，先在本機跑一個有實際 console／network 活動的頁面（本機開發伺服器即可），純靜態頁面示範效果有限。
• Lighthouse 類場景建議在固定網路節流的受控環境跑，不要直接對正式站測，正式流量下分數本身會因真實網路狀況波動。

場景一：自動稽核修復迴圈

開發者 Cefas Garcia Pereira 手上的 Next.js 應用，Lighthouse 四項分數卡在 60 / 77 / 96 / 92（Performance / Accessibility / Best Practices / SEO）。他不想再手動「跑報告→對照程式碼→改→重測」繞圈子，想讓 Claude Code 自己把這個迴圈跑完，直到分數達標為止。

Claude Code 怎麼做

1. 1

   先跟 Claude Code 講清楚兩件事：目標分數（他設 90 分）跟最多跑幾輪（他設 3 輪），不要讓它自己決定要跑到什麼時候。

2. 2

   明文加護欄：「修東西之前不准自己裝或移除套件，要先問我」——這條是他自己踩過坑之後補上的，因為早期版本的迴圈曾經「移除了一些套件、殺掉了幾個流程」，可能是誤判某些依賴不需要。

3. 3

   每輪迴圈固定四步：build 應用 → 啟動本機伺服器 → 跑 Lighthouse 稽核 → 停止伺服器，再依報告內容修程式碼。

4. 4

   全部跑完後要求輸出一份異動摘要，方便事後 review 到底動了哪些檔案。

請針對這個 Next.js 專案跑 Lighthouse 稽核-修復迴圈：
目標：Performance / Accessibility / Best Practices / SEO 四項都到 90 分以上
上限：最多跑 3 輪，每輪固定走 build → 啟動本機伺服器 → 跑 Lighthouse 稽核 →
     停止伺服器 → 依報告修復
護欄：修程式碼前不准安裝或移除任何套件，需要動 package.json 一定要先問我
每輪結束後：附上這輪改了哪些檔案、為什麼改

跑完 5 次迭代，四項分數從 60 / 77 / 96 / 92 拉到 92 / 100 / 96 / 100 全數達標。要提醒的是，Lighthouse 分數本身在真實網路環境下重跑會有波動（同一頁面這次可能 95 分、下次變 88 分），要在固定網路節流的受控環境跑，同一批分數才有可比性，不能跑一次就當定論。

換成 Codex CLI

Codex CLI 目前找不到這個場景的第一手案例，但用它的通用能力應該也能做到類似效果：Codex CLI 支援同一款 lighthouse-mcp server（見場景三提到的官方工具鏈），理論上可以套用同樣的「稽核→修復→複測」迴圈邏輯，只是目前查證到的素材是工具說明文件本身，還沒找到真人實際跑過這個確切迴圈、附具體分數對比的敘述。

場景二：動畫幀洩漏根因

一款類 ChatGPT 的聊天介面產品（作者 Nikolai Lehbrink 稱為 meinGPT）隨著對話訊息數增加，畫面愈用愈卡，使用者能實際感受到掉幀。團隊一開始直覺懷疑是 React 重渲染太頻繁，但沒有工具能直接證實這個假設。這是這批研究裡最具體、最可查證的單一真實 bug 修復案例。

Claude Code 怎麼做

1. 1

   先用 react-scan 分析，結果顯示 1203ms 的總耗時裡只有 109ms 花在 React 渲染本身，其餘 1094ms 都耗在 JS 執行、DOM 更新與繪製幀——先排除「React 渲染慢」這個直覺假設，把懷疑方向轉往別處。

2. 2

   用 agent-browser（瀏覽器自動化工具）搭配 Chrome profiler 的 profiler start / profiler stop，讓 Claude Code 自動記錄「發送同一則串流 prompt」前後的完整效能追蹤檔（單次追蹤檔超過 360MB）。

3. 3

   Claude 比對追蹤檔找出根因：自訂 hook useSmoothTypingText 在 setState 的更新函式內部呼叫了 requestAnimationFrame，違反「更新函式必須是純函式」原則——React 在並發渲染下會多次呼叫這個更新函式，每次呼叫都各自產生一條新的 rAF 鏈，數以百計的自我複製迴圈互搶主執行緒。

4. 4

   修復方式：把 requestAnimationFrame 移到更新函式外部，改用 ref 鏡射進度值，讓更新函式保持純粹，只維持單一 rAF 鏈。

5. 5

   用同一套 agent-browser + profiler 流程重播同一個串流 prompt，比對修復前後的 rAF 呼叫次數作為驗收證據。

用 agent-browser 打開這個聊天介面的本機環境，執行以下流程：
1. 呼叫 profiler start 開始記錄效能追蹤
2. 送出一則會觸發串流輸出的訊息，等輸出完全結束
3. 呼叫 profiler stop 停止記錄
4. 分析追蹤檔，找出主執行緒被佔用最多的呼叫來源，
   特別留意 requestAnimationFrame 是否在某個 setState 更新函式內被呼叫

修復前 8 秒內產生 437,190 次 rAF 回呼（平均每幀約 900 次），畫面幀率掉到 4fps；修復後 8 秒內只剩 778 次 rAF 回呼，幀率回穩到 60fps。這個案例最大的教訓是：效能診斷要先用 react-scan 這類工具排除「不是 React 渲染慢」的可能性，再往下挖，不要一開始就假設是元件重渲染問題，否則會在錯的方向最佳化（例如亂加 React.memo）卻治標不治本。

換成 Codex CLI

Codex CLI 目前找不到這個場景的第一手案例，但用它的通用能力應該也能做到類似效果：Codex CLI 搭配 chrome-devtools-mcp 的 performance_start_trace / performance_analyze_insight 工具，概念上可以做到類似的「修復前後追蹤檔比對」，只是目前還沒查到有人實際用 Codex CLI 跑過這個確切 bug 類型並附上對比數字的紀錄。

場景三：瀏覽器現場直讀

如果說前兩個案例是盯著分數與追蹤檔的效能戰場，這一個案例換到除錯的日常戰場：傳統開發流程是「改程式碼→切到瀏覽器→開 DevTools 看錯誤→切回編輯器」不斷重複的 context-switch。工程師 samwize 想測試 Claude Code 能不能直接讀到一個有登入牆的網站的實際 network request，而不是靠自己開 DevTools 複製貼上。

Claude Code 怎麼做

1. 1

   安裝 chrome-devtools-mcp（挑一種即可）：

   # 純 MCP
   claude mcp add chrome-devtools npx chrome-devtools-mcp@latest
   
   # 含 Skills 的完整外掛（Chrome 官方推薦）
   claude plugin marketplace add ChromeDevTools/chrome-devtools-mcp
   claude plugin install chrome-devtools-mcp@chrome-devtools-plugins

   複製
2. 2

   用 /mcp 確認 chrome-devtools 顯示已連線。

3. 3

   直接下 prompt 問瀏覽器目前的狀態，不必自己先開 DevTools 看一輪。

4. 4

   Claude Code 會呼叫 list_pages / navigate_page / take_snapshot / list_network_requests 這些工具直接讀實際資料，不是靠截圖用猜的；文字快照（accessibility tree）比截圖快，DOM 互動也優先用元素 ID 而非座標點擊。

瀏覽 localhost:3000，讀取 network 請求記錄，
找出所有回應狀態碼不是 2xx 的請求，
列出對應的 request URL、方法與回應內容

samwize 的實測案例：讀取一個登入牆後網站的 network request，直接找到內部 cciobjects.json API 端點，一次性擷取 35 篇文章的標題、署名、全文並摘要出 5 篇重點，效率遠高於逐頁截圖。chrome-devtools-mcp 官方列出提供 29 個工具，涵蓋輸入自動化、導航、效能、網路、除錯、記憶體六大類；但要留意 token 消耗——另一位工程師 goodbran 實測「幾次涉及頁面導覽與截圖的查詢後，消耗約 500 萬個 token」，因為完整 DOM 樹、computed style、metadata 都會塞進 context window，建議只在需要時啟用，不要預設常駐開著。

換成 Codex CLI

這是少數 Codex CLI 有官方對應動作的場景：OpenAI 於 2026 年 6 月推出 Developer 模式，讓 Codex 取得 Chrome DevTools Protocol 的完整存取權，可以讀 console 錯誤、network 流量、DOM／樣式狀態、效能追蹤，官方宣稱透過最佳化 DOM 快照讓瀏覽器操作速度「提升至 2 倍」。這個功能預設關閉，需要明確授權開啟，且底層跟 Claude Code、Gemini CLI、Cursor 共用同一套開源的 chrome-devtools-mcp（並非 OpenAI 獨有技術）。目前查到的示範案例（一個「反應緩慢的聊天應用」的效能分析）沒有附具體的前後數字對比，屬於官方示範轉述，不像 samwize、goodbran 這兩個 Claude Code 案例那樣有具體數字可查證。

場景四：CORS 除錯陷阱

前端呼叫自家 API 時，瀏覽器 console 跳出「No 'Access-Control-Allow-Origin' header present」。Charles Kern 在審查自己經手的五個不同專案時，發現同一個模式反覆出現：AI 編輯器（含 Claude Code）在生成 CORS 設定時，慣性寫出 app.use(cors()) 這種等同全開放萬用字元的寫法。

Claude Code 怎麼做

1. 1

   打開瀏覽器 Network 標籤，展開失敗的 request，先讀 Origin request header——伺服器必須原樣回傳這個值（含 scheme 與 port）在 Access-Control-Allow-Origin 裡。

2. 2

   檢查 response 有沒有 Access-Control-Allow-Origin，值是否等於 origin 或萬用字元 *，缺漏就是伺服器端要補設定。

3. 3

   對 Claude Code 下指令，讓它透過 Chrome 整合自動抓 network request 標頭，定位到伺服器端 CORS 設定程式碼並修正。

   瀏覽器呼叫 /api/data 時 console 顯示 CORS 錯誤，
   讀取這個 request 的 network 標頭細節，
   定位伺服器端的 CORS 設定程式碼並修正，
   但先告訴我你打算怎麼改，不要直接把 origin 設成萬用字元

   複製
4. 4

   修完之後務必自己核對：常見錯誤修法陷阱是直接設 origin: '*' 又同時開 credentials: true——瀏覽器會靜默拒絕對萬用字元來源傳送憑證，這個組合本身就是壞的。正確做法是用允許來源陣列＋callback 驗證來源＋明確設定 credentials 旗標。

Charles Kern 指出，這種萬用字元寫法會反覆出現，是因為訓練語料裡 Stack Overflow 最高票答案與大量教學程式碼都示範這種寫法——程式能執行、演示能跑，但正式環境並不安全。這不是除錯工具本身的問題，而是 AI 生成程式碼的通病，重點是工程師要主動用瀏覽器 Network 標籤驗證 Claude Code 生成的結果，不能照單全收；建議在部署前用 pre-commit hook 或 semgrep 之類的靜態分析工具再攔一次。

換成 Codex CLI

Codex CLI 目前找不到這個場景的第一手案例，語料中沒有找到 Codex CLI 對應的 CORS 除錯案例記錄，這裡僅記錄 Claude Code 一側，標記為單邊語料——不代表 Codex CLI 做不到，只是目前沒有查到對應的真人實測敘述。

常踩的坑

延伸資源

• Using Claude Code to fix our most-reported bug — Nikolai Lehbrink
• How Claude Left My Lighthouse Scores at 100 (Or at Least Tried) — Cefas Garcia Pereira, Medium
• GitHub - ChromeDevTools/chrome-devtools-mcp
• How to Set Up Chrome DevTools MCP for Claude Code – samwize
• Why Claude Code Keeps Setting CORS to Wildcard in Your Express API – Charles Kern (Medium)