performance-optimization

performance-optimization skill 概覽

performance-optimization skill 的功能是什麼

performance-optimization skill 是一套以量測為先的工作流程，用來診斷並改善應用程式效能，而不是靠猜測亂試。它的核心任務很單純：先做 profile、找出真正的瓶頸、修正那個瓶頸，最後驗證結果。當你需要的是有紀律的效能優化流程，而不是泛泛的建議時，它會比一般「幫我變快一點」這類 prompt 更實用。

哪些人適合安裝

這個 performance-optimization skill 特別適合開發者、使用 AI 協作寫程式的人員，以及負責技術決策的 lead，尤其是正在處理 web app、frontend、API，或資料量大的功能，而且很在意延遲、載入時間或 Core Web Vitals 的情境。如果你已經有明確症狀或需求，例如互動卡頓、LCP/INP/CLS 表現不佳、bundle 過大、某次改動後出現 regression，或某些流量敏感的程式路徑需要優化，那它會很適合你。

安裝前的實際判斷標準

如果你想要的是一套可重複執行的優化流程，而不是期待神奇修復，那就適合安裝 performance-optimization。它最大的差異點，在於明確提醒你避免過早優化，並且把證據放在流程中心。若你要的是不經量測、直接套用各框架的效能調校配方，這個 skill 可能反而太講究流程。相對地，如果你需要一套方法，幫你判斷「應該先優化哪裡」，它就很對路。

如何使用 performance-optimization skill

安裝脈絡與第一個該讀的地方

要使用 performance-optimization skill，先把上層 skill collection 加到你的 AI coding environment，接著在任務中用名稱呼叫這個 skill，並附上可量化的效能目標。第一步請先閱讀 skills/performance-optimization/SKILL.md；這個 repository 路徑很重要，因為這個 skill 是自成一體的，沒有額外附帶 helper script 或外部參考資料。換句話說，輸出品質更依賴你提供的輸入，而不是某些隱藏工具。

performance-optimization skill 需要哪些輸入才會表現好

好的 performance-optimization usage，起點應該是證據，而不是模糊抱怨。請提供：

• 受影響的頁面、route、功能或 endpoint
• 目前的 metric 數值或實際症狀
• 你是怎麼量測的
• 環境細節：裝置、browser、network、dataset size、production 還是 local
• 如果你懷疑是 regression，請附上近期變更
• 限制條件，例如「不能做 framework migration」或「必須保留 SEO」

強輸入範例：

Use performance-optimization for our product page. Mobile LCP is 4.1s in Chrome, CLS is 0.18, and users report delayed hero rendering on 4G. We recently added a carousel and a third-party review widget. Please identify likely bottlenecks, suggest measurement steps, rank fixes by expected impact, and tell me how to verify improvement.

弱輸入範例：

Make my site faster.

如何把模糊目標改寫成可用的 prompt

一個好用的 performance-optimization guide prompt，通常會照這個結構來寫：

1. 先說明目標 metric 或使用者抱怨。
2. 提供 baseline 數字。
3. 說清楚範圍。
4. 補上程式碼或架構脈絡。
5. 要求依優先順序提出修正方案與驗證步驟。

範例：

Apply the performance-optimization skill to our React checkout flow. INP is ~320ms on mid-range Android during quantity changes. The page renders a large cart list, coupon validation runs on input, and analytics fire on every interaction. Help me measure the hot path, isolate the interaction bottleneck, propose code-level fixes, and define a before/after verification checklist.

實際工作流程與輸出期待

實務上，建議把這個 skill 分成四輪來用：建立 baseline、隔離瓶頸、設計修正方案、驗證結果。你也可以明確要求它把「假設」和「已確認發現」分開寫。如果你已經做過 profile，請直接貼上 traces、Lighthouse 輸出、DevTools 發現或 flamegraph 摘要；如果還沒開始量測，先請這個 skill 幫你設計 profiling 計畫。這也是 performance-optimization install 是否值得的一個關鍵判準：它在搭配真實量測結果與 repository 脈絡時最有價值，而不是拿來取代這些工作。

performance-optimization skill 常見問題

這會比一般的「optimize performance」prompt 更好嗎？

通常會，前提是你的目標是做出可靠的判斷。performance-optimization skill 預設採用更扎實的流程：量測、辨識、修正、驗證。一般 prompt 則常常一上來就建議 caching、memoization、lazy loading 或 code splitting，不管那些到底是不是實際瓶頸。

它只適用於 web performance 和 Core Web Vitals 嗎？

不是，但這個 skill 的確明顯偏重使用者可感知的效能訊號，而且有明確提到 Core Web Vitals 目標。它最自然的使用場景仍然是 frontend 與頁面速度優化；不過同一套流程也能處理 backend latency、資料處理變慢，或各種 regression，只要你能清楚定義「慢」是什麼，並且實際量測得到。

什麼情況下不該使用 performance-optimization？

當你手上根本沒有任何問題證據時，不要把 performance-optimization for Performance Optimization 當成第一步。如果沒有變慢、沒有效能預算、沒有 SLA，也沒有使用者抱怨，這個 skill 本身就不鼓勵你投入優化工作。另外，如果你期待的是開箱即用的 benchmark automation 或 framework-specific scripts，它也不太適合，因為這個 repository 並沒有附這類支援資產。

如何改進 performance-optimization skill 的使用效果

提供更精準的證據，而不是更大的需求範圍

想提升 performance-optimization 的輸出品質，最快的方法就是縮小範圍、把 metric 講清楚。像是「mobile 上的 checkout page，LCP 3.8s，懷疑是 image 和 font 問題」，效果就會比「整個 app 都很慢」好很多。有可能的話，請附上 screenshots、profiler 筆記、bundle reports、request waterfalls 或近期 commits。這個 skill 在有可觀察事實可用時，推理品質會明顯更好。

留意常見失敗模式

最常見的失敗模式，就是還沒確認瓶頸就急著要修法。另一種則是把太多症狀混在同一次請求裡：啟動很慢、互動延遲、API latency，通常需要分開調查。也盡量不要要求「所有可能的優化方式」；這只會得到一串泛泛清單，而不是有優先順序的行動建議。更好的問法是：請依預期影響、實作成本與驗證方式來排序修正項目。

在第一輪回答後持續迭代

第一輪完成後，請帶著結果再回來，例如：「We deferred the widget script and LCP improved from 4.1s to 3.2s, but INP is unchanged.」這樣 performance-optimization skill 才能從理論分析進一步轉成有引導性的迭代流程。最佳工作方式是循環式的：先有 baseline、一次只改一個有意義的變數、重新量測，然後再請它找出下一個影響最大的改善點，而不是一次套上十個還沒驗證的修正。