顧客頁面為何突然跳動？應先修正哪種版面位移？

先從顧客看到的跳動入手

頁面初看似已完成，仍可能在最不合適的時候移動。顧客正在閱讀送貨條款，上方突然插入橫幅；正要按「加入購物車」，產品圖片又把按鈕推走。需要處理的是妨礙閱讀或操作的意外位移，不是把所有動畫一律刪除。CLS 用來衡量這種視覺不穩定。Google 建議以手機及桌面分開看第七十五百分位數，理想值不高於 0.1。這只是判讀標準，不能拿來聲稱自己的網站已經達標。

改 CSS 前，先定義值得檢查的顧客流程。例如由搜尋結果進入產品頁，等待資料出現，捲到推薦商品，選擇款式，再由購物籃返回。記下裝置視窗大小、網絡情況、瀏覽器快取是否已有圖片，以及移動發生在哪一刻。只測一次頁面載入的 Lighthouse 結果，可能漏掉捲動後才出現的位移；真實使用數據則可能涵蓋較長的頁面生命週期。還要分清資料代表單一網址還是整個網域。手上若只有本機重播，就如實稱為重播，不能當作顧客實測。

版面位移記錄會指出哪些元素移動，但被標示的元素未必是原因。若送貨提示插到購買按鈕上方，工具可能把按鈕列為位移元素；真正原因卻是新加入的提示。在 Chrome DevTools 查看位移時序和前後畫面，再沿版面往上找突然變高或插入的區塊。除了數值，也要比較位置。這樣才不會只調整按鈕外觀，卻留下會推動整頁的橫幅。

預留空間並處理根因

圖片和影片通常是最容易先查的地方，因為下載前已可知道尺寸。提供原始寬高或合適比例，讓瀏覽器在載入期間先保留位置；同時保留響應式版面，實際測試窄屏及闊屏的裁切。正方形產品圖與橫向封面不能共用同一個預留形狀。若內容系統提供的圖片比例不一，需要訂立容器規則，並確認重要產品細節沒有被裁走。目標是內容真實而版面穩定，不是留一大塊沒有用途的空白。

第三方嵌入內容、廣告位、推薦組件及同意提示，都要在版面中有明確位置。按不同狀態預留空間，並讓載入失敗時不會先收縮再膨脹。若推廣訊息並非必要，可考慮放在既有區域或目前閱讀位置下方，避免突然插到操作按鈕前。本機快速網絡測試通過，不代表慢速網絡、另一個宣傳活動或較長的繁體中文文案也穩定。要測試最長的合理文案，以及第三方完全沒有回應的情況。

即使沒有圖片，字體載入也可能改變換行及區塊高度。英文與繁體中文都要比較後備字體和最終字體；窄卡片或按鈕上的中文換字體，可能比英文多出數行。選擇字形尺寸相近的後備字體，按需要檢視字體載入及度量調整方式，避免為等候裝飾字型而長時間隱藏文字。字體方案只有在保住可讀性時才有意義。真實字體到達後，亦要以放大文字、較長姓名及送貨地址重測換行。

用一個上線情景作決定

假設網店發現手機上的購買按鈕，總在運費估算器載入後移位。先比較首次進入和快取已暖的訪問，再於選擇送貨地區時重播時序。若新提示出現在按鈕上方，就在估算器旁預留訊息區，讓等待、成功和錯誤狀態在同一位置顯示。地區選擇本身可能合理地改變內容，但稍後回傳的結果仍不應把無關部分推走。這個流程先找原因再選修正方法，不預設外部服務或 CSS 一定有錯。

排序時要看對顧客的影響和是否容易重現。頁尾裝飾稍微移動，通常比下單時購買按鈕移走影響小，即使兩者都會計入同一指標。記錄頁面、視窗、觸發動作、受影響控制項、懷疑原因、修改方法和負責人。每次先修一個原因，下一次重播才容易解讀。若組件在多頁共用，選有代表性的情況核對：長短不同的產品名稱、有貨與售罄、英文與中文，以及沒有推廣模組的頁面。

修正後以相同條件重走原路，再改變裝置尺寸、快取狀態及網速。觀察捲動及返回流程，不要在首次畫面出現後就停止。確認預留區不會遮蓋控制項、留下過大空白或裁掉翻譯內容。日後再看可取得的真實使用數據，留意其統計時間窗；實驗室數值立即改善，不能直接寫成業務成效。當影響任務的位移消失，而且各測試狀態仍可使用，才有可交付的修正證據。

令修正容易維持

列出所有可能稍後才出現內容的組件：產品媒體、庫存狀態、運費估算、推薦商品、即時對話、同意面板及字體。每項都訂明初始空間、等待狀態、完成狀態及故障狀態，比籠統叫開發人員「改善 CLS」具體得多。這也能找出負責人：市場團隊可能換橫幅、商品團隊可能上傳比例特殊的圖片，第三方組件亦可能在部署後膨脹。每次修改都可按預留空間的約定檢查，避免下一個活動把 CSS 修正推翻。

不要把低 CLS 數值當成頁面完全可用。橫幅即使沒有推動元素，若蓋住按鈕，顧客仍無法操作；放大文字後的問題也可能是內容被裁走，而非位移。因此數值之外還要直接測試：鍵盤能否到達下一步、放大文字是否完整、提示出現後焦點標示有否被遮住。指標有助找出不穩定，驗收仍要看顧客任務。若只用僵硬高度壓住跳動，卻把內容截斷，便是用另一種問題掩蓋原本問題。

有些移動由顧客明確操作引發，是可以理解的，例如按開摺疊內容後，該區塊自然變高；但按鍵幾秒後才出現的運費結果，若把別處推走，感覺就不同。應按實際時間次序觀看互動及等待訊息。CLS 的定義會排除某些緊接輸入的位移，但這不代表所有延遲回應都可接受。把技術數值和人的觀察一起記在上線紀錄，並解釋兩者為何不同，日後維護者才知道當時的設計判斷。

上線後建立簡單覆核節奏：推出新推廣、圖片範本或字體時，重看重要頁面，手機和桌面分開檢查。如有實際使用數據，先確認覆蓋範圍及統計期，再判斷變化是否與某次發布有關；沒有數據時，保留可重複的操作路徑及簡短錄屏，清楚標示為內部測試。只要主要操作按鈕再次移動，即使整頁百分位數看似合格，也應處理。這樣團隊注意的是顧客風險，而非追逐漂亮數字。

發布紀錄應分開寫觀察、改動及剩餘風險。例如在內部測試中記錄：「手機首次載入後，運費結果回來時，提示出現在購買控制項上方；為提示預留區域後，以相同路徑重測，沒有再見到該次移動。」這是指定條件下的測試觀察，不能寫成所有顧客的體驗。另記下版本、頁面範本、裝置及已測狀態，讓下一次活動能重複檢查。若第三方組件仍無法預測，記錄受影響流程及可停用或替換它的負責人。可維持的修正是一項持續決定，不是一張安靜載入畫面的截圖。 驗證紀錄還應標明哪些情況尚未覆蓋，例如登入後的個人化內容、較少見的螢幕尺寸或節日活動素材。尚未覆蓋的情況應安排下一次具體測試，而不是寫成已通過。若手機及桌面結果不同，分別保存重現步驟及負責人，避免一邊的修正掩蓋另一邊的問題。