客戶不用新站，不是因為功能不好，而是因為「感覺太慢」。

這是我收到客戶成功部門回饋的那一刻，意識到的事。

最後結果

LCP 從 1.78 秒 降到 0.07 秒，全空白畫面縮短至 884 毫秒。

以下是我怎麼做到的。

為什麼這件事不能拖

某位大型客戶明確表示：新站首頁的長資訊清單顯示速度比舊站慢，所以繼續用舊站。

這不只是 UX 問題。我們正計畫將所有客戶平滑遷移到新站。如果遷移當下客戶大量反映相同問題，短期增加預料外的客服負擔，長期讓工程團隊疲於應對客訴，無法專注在真正重要的事。

所以我決定先自己走一遍客戶的使用旅程。

找出真正的問題

我沒有從技術指標出發，而是先問：「使用者在等待的過程中，他的心理狀態是什麼？」

對比新站和舊站的使用體驗，找到兩個關鍵差異：

1. 全空白畫面持續太久——使用者沒有任何視覺反饋，無法判斷系統是否在運作
2. 長資訊清單顯示時機比舊站晚——即使前端已取得部分資料

用 Chrome DevTools 的 CrUX 工具量化差距：新站 LCP 1.78 秒，舊站 0.39 秒。不是主觀感受，是可測量的問題。

進一步分析發現，長資訊清單使用即時計算，導致 HTML DOM 持續偵測變化、高頻率重建元素。借助 AI 工具加速定位，確認首頁還有其他幾個潛在的高計算區。

解決方案

核心目標只有一個：消除使用者對「開啟新站很慢」的印象。

方向一：改變內容出現的順序（感知優化）

與其等所有資料就緒才渲染畫面，不如把載入過程拆成階段性反饋：先給產品圖 → App Shell → 局部資訊（附載入中圖示）→ 第二階資料到齊後才開放操作。

這個設計讓使用者在等待過程中一直有視覺錨點，「感覺慢」的問題本質上是感知問題，不是速度問題。

方向二：減少不必要的 DOM 計算

使用預先計算取代即時計算。trackBy 在清單資料結構穩定時效果有限，但這個場景的資料頻繁異動，搭配預先計算才能真正減少 DOM 重建次數，避免瀏覽器在每次更新時重建整個列表。

選擇這個組合而非其他方案的原因：改動範圍最小、風險最低，且可在不影響現有功能的情況下分階段驗證效果。

這件事讓我記住的一件事

客戶說「太慢」，但真正讓他們放棄的，是「不知道什麼時候才有東西可以用」。

技術指標是工具，不是目的。真正的問題永遠在使用者那一側。