實用檢查清單
開始前先確認這五項
- 選有代表性的首頁、服務頁及產品頁。
- 記錄受影響的實際任務。
- 標明實際用戶資料與測試結果。
- 以相同條件比較修改前後。
- 修正後重新測試查詢及語言切換。
先描述哪個步驟令人覺得慢
「網站要快一點」未必足夠估價或驗收。先寫明任務:閱讀服務介紹、打開導覽、篩選產品,還是提交查詢;再記錄畫面是空白、按鈕遲遲沒有反應,還是內容突然移動。
選幾種有代表性的模板。含影片的首頁、以文字為主的服務頁,以及有相簿的產品頁,表現可能不同。海外買家若從直接連結進入產品頁,只測首頁便可能遺漏真正問題。
用三個指標理解體驗
Core Web Vitals 以 LCP、INP 和 CLS 觀察載入、回應及視覺穩定性。目前良好門檻分別為不多於 2.5 秒、200 毫秒及 0.1,按第 75 百分位評估。這些是體驗指標,不能直接換算成銷售保證。
把指標轉成具體提問:主要產品圖出現晚,要檢查該頁的載入次序;選單回應慢,要檢查互動;按鈕隨圖片載入跳動,要查看是否預留合適空間。單一總分不能代替這些診斷。
分開看測試與實際用戶資料
實驗室測試使用指定條件,實際用戶資料則來自已記錄的訪問。裝置、網絡和使用方式不同,結果可能有差異。網站訪問量不足時,亦可能沒有足夠實際資料,應記作「未有資料」,而非自動視為通過。
保留工具、日期、網址、裝置設定和測試條件。結果不穩定時可合理重測,但不要一直測到最漂亮的分數才截圖。提供代表性觀察及限制,會比一個沒有背景的綠色分數更有用。
檢閱真正需要的圖片及外部功能
將首頁影片、大圖、預約嵌入、聊天工具和分析標籤列出,指定各自的業務負責人。討論哪些必須首屏出現、哪些可以稍後載入,而不是只為提高分數便移除買家需要的預約路徑。
服務海外買家的香港企業,可以按需要從相關地區檢查體驗。辦公室的高速網絡未必代表買家情況。首輪修正可以很小,例如處理一張過大的主圖,再用同一個任務重新測試。
驗收時保留功能與內容
要求在相同條件提供修改前後結果、變更項目,以及表格、導覽和語言切換的驗證。如果改了共用模板,要再查看另一個使用該模板的頁面,避免改善一處卻破壞其他內容。
日後新增影片或外部工具時,先確認用途及負責人,再觀察它對主要路徑的影響。速度維護應成為發布流程的一部分,讓團隊知道甚麼情況需要重新檢查,而非每次網站變慢才整站重做。
資料來源與適用範圍
- web.dev:Core Web Vitals 指標與門檻(英文)web.dev
技術參考;本文情境及檢查流程為編輯建議。
- web.dev:實驗室與實際使用者資料的分別(英文)web.dev
技術參考;本文情境及檢查流程為編輯建議。
