效能問題很容易引發大量修改：加快取、拆檔案、延後載入。但如果沒有先量測，就很難知道改動是否解決了真正的瓶頸。
描述一個可重現的情境
先固定頁面、操作、資料量與裝置條件。記錄慢的是第一次開啟、點擊之後的回應，還是捲動時的畫面。
同一個頁面可能同時有不同問題，不需要一次解決所有事情。
沿著等待時間往下找
可以把觀察分成幾段：
| 階段 | 觀察方向 |
|---|---|
| 回應 | 首個回應是否耗時？ |
| 傳輸 | 是否下載過大的程式與圖片？ |
| 執行 | 主執行緒是否有長時間工作？ |
| 顯示 | 是否有反覆的版面計算或畫面位移？ |
這些方向用來建立假設。真正的原因仍需要結合開發工具、程式碼與使用情境判斷。
做一個能比較的實驗
每次改動盡量只針對一個假設。例如移除某個不必要的客戶端元件，再比較同一條件下的載入工作量。
保留原始結果，避免只記錄最好看的那一次。若變化很小，先確認測量誤差，再決定是否保留修改。
別讓優化增加維護成本
不是每個運算都需要記憶化，也不是所有資料都需要快取。額外的機制也需要處理失效、狀態一致性與除錯。
真正好的優化，可以說清楚它改善哪段等待、用了多少成本，以及如何防止問題再次出現。