工具與技巧只是手段。真正讓優化有效率的，是一套「先量測、抓瓶頸、持續累積」的工程思維。本章把幾個放諸四海皆準的工程原則，落地成前端效能決策的判斷準則，避免把時間花在沒有回報的地方。

先量測，再優化#

「沒量測過的優化，多半是猜測。」

你選擇「測什麼」，會反過來決定你「優化什麼」。先確認指標反映的是真實的使用者體驗，否則很容易為了讓數字變漂亮，卻沒讓使用者更有感。

人對「哪裡慢」的直覺經常出錯。常見的反例：

• 花一週手刻演算法優化某個函式，結果它只佔總載入時間的 1%。
• 為了省 5KB JS 大費周章，卻放著一張 2MB 的未壓縮主視覺圖不管。

所以順序永遠是：用 Performance / Lighthouse 面板量出實際耗時分布 ➡️ 找出真正的大頭 ➡️ 才動手。相關工具見 02-performance-analyzers。

瓶頸思維：Amdahl 定律#

優化某個環節能帶來多少整體加速，受限於「這個環節原本佔多少比例」。這個關係就是 Amdahl 定律：

              1
加速比 = ───────────────
         (1 - p) + p / s

p = 被優化部分原本佔總時間的比例
s = 該部分被加速的倍數

它給前端最重要的啟示是：優化非瓶頸的部分，整體收益有上限。

舉例：假設頁面載入總時間中，圖片佔 60%（p = 0.6），其餘佔 40%。

• 就算把圖片載入「無限加速」（s ➡️ ∞），整體最多也只快到 1 / (1 - 0.6) = 2.5 倍。
• 反過來，若某段 JS 只佔總時間 5%，就算把它優化掉，整體最多省 5%。

const speedup = (p, s) => 1 / (1 - p + p / s);

speedup(0.6, 4); // 把佔 60% 的圖片加速 4 倍 → 整體約 1.92 倍
speedup(0.05, 100); // 把佔 5% 的部分加速 100 倍 → 整體僅約 1.05 倍

動手前先估一下 p：這個東西到底佔多少？佔比小的，再怎麼優化都不划算。把力氣放在佔比最大的環節，才是高槓桿的選擇。

複利效應：持續的小改進#

效能不是「一次到位」的專案，而是「持續維護」的習慣。每次 commit 多省一點，長期累積出來的差距非常可觀。

把每次優化想成複利。即使每週只改善 1%，一年下來：

1.01 ^ 52 ≈ 1.68 倍

落實到團隊，就是把效能納入日常流程，而非偶爾辦一次「效能衝刺」：

• 在 CI 加上 Lighthouse / bundle size 預算門檻，回歸時自動擋下。
• code review 時順手看一眼：有沒有引入肥大的依賴、沒有 lazy load 的大圖。
• 追蹤長期趨勢線，而非單次分數。

別被量測誤差騙了#

效能數據本身有雜訊：網路波動、機器負載、瀏覽器版本都會讓同一個頁面的分數上下跳。

單次分數的小幅變動（如 ±3 分）通常落在誤差範圍內，不代表真的變好或變壞。 別為了追逐單次數字頻繁調整，反而引入風險。

務實做法：

• 跑多次取中位數，而非只看一次。
• CI 門檻留一點寬容（如設 0.9 而非 1.0），避免被雜訊頻繁誤報。
• 用真實使用者監測（RUM）的長期趨勢，補足實驗室數據（Lab data）的侷限。

小結#