前端效能優化：我在實務專案裡真正會做的事

我是後端背景的全端，前端主力是 Vue，但效能優化的原則其實跨框架相通。這篇講的不是某個框架的 API，而是我在實際專案裡真正會去做、也真正有感的前端效能優化——以及我刻意「不做」的過早優化。

先量測，再優化

最重要的一條原則：不要憑感覺優化。 在動手之前先用瀏覽器的開發者工具（Performance、Lighthouse、Network）量測，找出真正的瓶頸在哪。

我看過太多人花一堆時間去微調一段根本不慢的程式，真正的瓶頸卻是一張沒壓縮的大圖。沒有量測的優化，常常是在解決不存在的問題。先找到那 20% 真正拖慢體驗的東西，把力氣花在那裡。

載入效能：使用者最先感受到的

使用者對「快不快」的第一印象，來自頁面載入。我會優先處理：

• 圖片：這幾乎是最常見的元兇。用適當的格式與尺寸、壓縮、延遲載入（lazy load）那些不在第一屏的圖。一張過大的圖能毀掉整個首屏速度
• 打包體積：別把整包 JavaScript 一次塞給使用者。用程式碼分割（code splitting），讓使用者只下載當前頁面需要的部分
• 第三方腳本：每加一個第三方腳本都是成本。廣告、分析工具這些要斟酌，它們很容易拖慢頁面

渲染效能：避免不必要的重繪

不管是 React 還是 Vue，核心問題都一樣：避免不必要的重新渲染。當資料變動時，只更新真正需要更新的部分，而不是一大片元件全部重畫。

• 把狀態放在「剛好需要的層級」，不要讓一個小變動觸發整棵元件樹重繪
• 大型清單用虛擬化（只渲染畫面上看得到的那幾筆），而不是一次塞幾千個 DOM 節點
• 善用框架提供的快取機制（Vue 的 computed、React 的 memo），但別濫用——過度的 memo 反而增加負擔

狀態管理：別讓它變成效能黑洞

前端一複雜，狀態管理就容易出問題。我的原則是把共用狀態集中管理（Vue 我用 Pinia），並且讓元件只訂閱它真正需要的那部分狀態。如果一個全域狀態一變，全站元件都跟著重繪，那就是效能黑洞。

別過早優化

最後，跟後端一樣：過早優化是萬惡之源。 在功能還沒穩定、還沒量測之前就為了效能把程式寫得很扭曲，往往得不償失——你犧牲了可讀性，去換一個可能根本不存在的效能問題。

我的順序永遠是：先把功能寫對、寫清楚 → 上線量測 → 找到真正的瓶頸 → 針對性地優化。

小結

我在實務專案做前端效能優化的原則：

• 先量測再優化，別解決不存在的問題
• 載入效能優先處理圖片、打包體積、第三方腳本
• 渲染上避免不必要的重繪，大清單用虛擬化
• 狀態集中管理、精準訂閱，別讓它變效能黑洞
• 不要過早優化，先求對與清楚，再針對瓶頸下手

效能優化的功力，不在於你會多少技巧，而在於你能不能克制住「到處優化」的衝動，把力氣花在真正有差別的地方。