web-perf
作者 cloudflareweb-perf 透過 Chrome DevTools MCP 分析網站效能。它會衡量 Core Web Vitals、以 trace 為基礎的載入問題、阻擋渲染的資源、版面位移、快取問題與可及性缺口。若你需要 Performance Optimization、除錯緩慢頁面，或依據最新文件與即時 traces 進行的 web-perf 指南式工作流程，都適合使用 web-perf skill。
這個 skill 的評分是 84/100，表示它很適合需要具體網站效能工作流程的代理程式目錄清單。這個 repository 提供的證據已足夠讓使用者判斷是否安裝：它清楚界定此 skill 以 Chrome DevTools MCP 為基礎進行效能分析，列出目標指標與失敗模式，並包含 MCP 可用性的必要預檢。使用者仍需預期自行設定 DevTools MCP server，且部分內容會依賴外部文件擷取，但整體安裝決策價值仍然很高。
- 觸發條件明確：frontmatter 直接指出可用於稽核、剖析、除錯或最佳化頁面載入效能、Lighthouse 分數與網站速度。
- 操作清楚：它指定先做 MCP 可用性檢查，若工具缺失，還提供完整的 chrome-devtools MCP 設定片段。
- 對 agent 的幫助具體：它鎖定 Core Web Vitals 以及阻擋渲染的資源、相依鏈、版面位移與快取問題，比一般性的效能提示更可執行。
- 需要可正常運作的 Chrome DevTools MCP 設定；如果工具不可用，skill 會指示 agent 停止並要求調整設定。
- 部分指引刻意依賴檢索而非完全自包含，因此使用者仍需仰賴外部文件取得門檻值與工具細節。
web-perf 技能概覽
web-perf 的用途
web-perf 技能可透過 Chrome DevTools MCP 來稽核並改善頁面速度，而不是只憑截圖或單一 Lighthouse 分數去猜。它聚焦於 Core Web Vitals、trace 追蹤診斷、網路 waterfall、render blocking、layout shifts、快取，以及相關的無障礙／效能問題。
適合誰使用
如果你需要針對真實網站做實際的效能調查，尤其是想釐清頁面為什麼感覺很慢、某個指標為什麼退步，或是哪個資源拖慢載入，這個 web-perf 技能就很適合。對於重視證據勝於泛泛建議的 Performance Optimization 工作，它特別有用。
web-perf 的差異在哪裡
web-perf 的核心價值，在於它偏向即時擷取最新文件與 DevTools 資料，而不是依賴過時的心智模型。這讓它更適合需要精確指標定義、trace 解讀，或當前工具行為的決策。若是廣泛的 SEO 稽核，或不需要效能追蹤的設計評論，它就沒那麼適合。
如何使用 web-perf 技能
安裝並驗證環境
先透過你的 skills manager 執行 web-perf install 流程，然後在要求分析之前，確認 Chrome DevTools MCP server 真的可用。這個技能預設能存取 DevTools；如果 MCP 工具不存在，流程應該及早停止，而不是憑空產生結果。
提供有「效能樣貌」的提示詞
一個好的 web-perf usage 提示詞，會清楚寫出頁面、症狀，以及 agent 需要重現或檢查的情境。例如：「稽核行動版首頁在最近一次發佈後的 LCP 退化。重點看阻擋式 CSS、主視覺圖片傳遞，以及 trace 證據。」這比「讓這個網站變快」更好，因為它告訴技能該量什麼、看哪裡。
先讀對的檔案
先從 SKILL.md 開始，再沿著 repo 內連結的文件去看，了解 retrieval 來源、工具檢查或分析步驟。這個 repo 沒有額外的 helper 資料夾，所以主要判斷點都放在技能檔本身。特別注意那些要求 agent 驗證 MCP 工具、優先使用 retrieval，以及以 trace 證據而非假設為準的段落。
採用符合問題的工作流程
如果是診斷，請要求 trace 支撐的根因分析，再附上簡短修正清單。若是最佳化，請先要求最大機率的收益，而不是一份鉅細靡遺的清單。若是追查 regression，請提供變更前／後的內容、URL、裝置類型，以及你更在意 LCP、INP 還是 CLS。輸入越具體，模型就越不需要猜 web-perf guide 該走哪條路。
web-perf 技能 FAQ
web-perf 只適合 Lighthouse 式稽核嗎？
不是。它可用於 Lighthouse 相關工作，但更強的用途是透過 DevTools MCP 做 trace 式除錯。也就是說，它不只幫你知道指標變了，還能幫你理解為什麼會變。
我需要很熟 Chrome DevTools 嗎？
不一定。只要你能清楚描述問題，這個技能對初學者也很有幫助。你不需要是 trace 專家，但你需要提供足夠的情境，讓 agent 知道哪個頁面、哪種裝置、以及哪個症狀最重要。
什麼情況下不該用 web-perf？
如果你要的是一般性的前端重構、視覺設計審查，或一個不依賴執行時證據的答案，就不要用它。如果你無法提供要檢查的頁面，或者沒有可用的 DevTools MCP，這個技能就會被阻擋。
它比一般提示詞好在哪裡？
一般提示詞通常只停留在高層次。web-perf 技能更可執行，因為它會把焦點拉向最新文件、明確的工具檢查，以及可量測的原因，例如 render blocking、依賴鏈、layout shift 來源與快取行為。對 Performance Optimization 來說，它比一次性的聊天指令更有力。
如何改進 web-perf 技能
提供可追蹤的輸入，不要只有模糊目標
要讓 web-perf 的結果更好，最有效的方法就是給它 URL、目標裝置、測試條件，以及你最在意的指標。「改善結帳速度」太弱；「在中階 Android、快速 4G 條件下，針對新主視覺橫幅上線後的 LCP 與 CLS 稽核 checkout」就清楚得多。
提供變更時間窗與可疑原因
如果你知道哪裡變了，就直接說。發佈說明、最近的 CMS 更新、新的第三方腳本，或重新設計的 hero，都能把調查方向拉對。這能幫助技能優先測試最可能的原因，而不是盲目掃描整個頁面。
要求證據與優先排序的修正路徑
有用的 web-perf 輸出，應該把已確認的原因和推測中的原因分開，並依照使用者影響與實作成本排序修正項目。如果第一版答案太籠統，就要求列出前兩個瓶頸、它們背後的 trace 證據，以及最小且安全的變更來驗證是否改善。
用前後量測持續迭代
把第一輪當成診斷，而不是結案。修正完成後，用相同的頁面與條件再跑一次相同的 web-perf 工作流程，讓輸出能一致地比較 trace 證據與指標。這是把 web-perf guide 變成可重複最佳化循環的最快方式。