結帳按鈕反應慢：改版前如何找出 INP 問題

先說清顧客看到的慢

顧客在結帳頁按「繼續」，畫面似乎毫無反應。這句投訴可能指幾種不同等待：瀏覽器忙於其他工作，未開始處理觸控；按鍵處理程式做了太多事；新畫面繪製太慢；或付款請求正等待網絡回應。這些要分開查證。Interaction to Next Paint（INP）量度一次瀏覽期間，網頁對合資格操作顯示下一個畫面的速度；它不是付款完成或訂單電郵送達的計時器。結帳頁可很快顯示「處理中」，付款確認仍可能較遲回來。反過來，付款服務即使很快，按鈕凍結也會令顧客覺得網站慢。第一步是確定顧客究竟等的是哪一段。

Google 的網頁效能指引把 INP 不超過 200 毫秒視為良好，超過 500 毫秒視為較差，中間則需要改善，並建議分開看手機及桌面瀏覽的第 75 百分位數。這些是指標界線，不是承諾每次點按都會在 200 毫秒內完成。小店不應憑一部辦公室電腦或一次自動評分，就宣稱結帳很快。若網站訪客不多，實際使用資料可能不足以可靠分類。此時可用可重複的裝置和網絡測試找出問題，但結論應標明為測試發現，而非整體顧客已量得的結果。

從真實使用情況找出慢操作

先記下顧客回報的結帳步驟、裝置類別、瀏覽器及操作。只有整頁 INP 數字，無法知道慢的是選送貨方式、輸入地址、按優惠券，還是最後提交。若網站已有合適的真實使用量測，可查看造成延遲的操作目標及時間分段，並把受影響的手機瀏覽與一般瀏覽比較。Google 的實地診斷指引列出輸入延遲、程式處理時間和畫面呈現延遲等歸因資料。效能事件只應收集查錯所需的技術背景，不要附上姓名、卡資料、地址或表格輸入內容；新增分析事件前，亦要檢查相關同意及私隱處理。沒有實地數據就如實說明，再從顧客回報與受控重現入手。

要在有代表性的手機上重現完整流程，包括會更新頁面的送貨和付款選擇。除了開發電腦，也試較慢的裝置，並記下延遲發生於初次載入時，還是頁面穩定後。可用瀏覽器效能工具記錄點按至下一幀畫面，但不要把真實付款資料放進會分享的追蹤檔。重複操作幾次，看問題是否穩定；單次紀錄可能剛巧遇到背景工作。以簡表寫下操作、裝置、瀏覽器、觀察到的延遲和懷疑的階段。這是診斷方法，不能代替顧客群體數據。受控追蹤讓開發人員知道從哪裏查起；真實使用資料則幫店舖了解影響有多廣。

分清慢反應的三個階段

若主要是輸入延遲，代表瀏覽器在開始處理點按前已忙於其他工作，可查頁面啟動時的長任務、定時工作或同時執行的第三方程式，把與當前操作無關的工作移離這段時間。若主要是程式處理時間，就查看按鍵處理器本身：是否每次都重新驗證所有欄位、同步解析大量清單、做昂貴計算，或連續觸發多次更新。必要的檢查要保留，但可避免重做可安全緩存或稍後處理的工作。若主要是畫面呈現延遲，處理器可能已完成，瀏覽器仍要做大量樣式、排版或繪圖工作才可顯示回應，這時應縮小變動範圍並避免反覆重新排版。Google 的改善指引把這些階段分開，因為各自需要不同方法。

不要把非同步等待伺服器誤當作 INP 問題。網絡請求可以花時間，而瀏覽器仍可先顯示清楚的等待狀態。顧客仍需知道請求已收到、目前是否待處理，以及失敗時怎樣辦。應及時呈現符合真正伺服器狀態的視覺回應，防止意外重複提交，並在結果確定後更新狀態；未獲伺服器確認前，不可先顯示訂單已完成。相反，若長時間同步程式執行完才出現轉圈圖示，也無助於改善剛才像沒反應的點按。合理次序是迅速回應輸入、讓介面保持可用，再準確交代交易結果。

以結帳例子選擇修正方法

假設一家店舖的送貨選項只在中階手機上反應慢。追蹤顯示，點按要等一段重建大量推薦產品的程式完成，而推薦內容與送貨資格無關。團隊便把這項非必要更新移到選項畫面顯示之後，再以同一手機及路徑測試，確保送貨選擇正確、訂單金額沒有變。另一情況是瀏覽器已很快回應，但運費報價服務需等很久；此時應改善等待與錯誤提示，並調查該服務，而非聲稱改善 INP 便會令報價更快。兩個都是示範情境。它們說明修正方法應由時間分段的證據決定，而不是開一張籠統的「加快網頁」工作單。

應優先處理既慢又關乎完成購買的操作。罕用裝飾按鈕也可量度，但地址修正或送貨選擇延遲更可能令顧客放棄下單。除觸控外，還要測試鍵盤操作，因為程式路徑或焦點更新可能不同。失敗情況也要試：地址無效、送貨方式不可用和付款被拒時，都要及時、清楚交代。若為了速度而移除驗證或隱藏錯誤，只是拿準確性換表面快捷。記錄修改內容、促使修改的追蹤結果和驗收準則。業務真正要判斷的是顧客能否理解並完成流程，不只是某個指標有否移動。

不要只看一次分數便結案

應在同類裝置上重測同一操作，比較修改前後的追蹤紀錄。若有實地數據，再觀察足夠的正常使用情況，看看手機結帳是否改善，其他地方有否出現新故障。比較時要用同一頁面和操作，亦要留意顧客及裝置組合有否改變，才可宣稱改善。交易成功、重複提交和客服投訴應另行監察；按鈕反應快，不代表訂單一定正確。若實地資料太少或不可用，就如實報告受控測試結果與資料缺口。實際結案標準，是結帳頁能及時回應每項操作、維持正確訂單邏輯，並把購買的真實狀態告訴顧客。

把改善要求寫得具體

有效的改善要求要指出操作和預期回應。例如：顧客在有代表性的手機上更改送貨方式時，選擇應立即有可見反應；顯示費用要與伺服器計算一致；報價失敗時要有清楚的恢復方法。附上追蹤紀錄，說明主要延遲在輸入排隊、處理程式還是畫面呈現。列出可稍後執行的功能，以及必須即時保持的正確性規則。這讓開發者減少多餘工作時，不會意外改變價錢、庫存或資格判斷，也讓店主按顧客流程驗收，而非只批准一個含糊的效能分數。

證據範圍要與問題相稱。若只有套用優惠券後才可重現慢操作，就測該路徑及一般路徑，不必把全站每頁都做同樣追蹤。若問題只在使用一段時間後出現，便要保留該段時間累積的頁面狀態。修正後，除下一幀畫面外，還要核實焦點位置、可見狀態、訂單金額和最終伺服器回應。改善瀏覽器指標的價值，在於顧客操作也更清楚、更可用。紀錄應寫明在甚麼裝置和日期觀察到甚麼，哪些仍未確定。這樣才不會把一項受控測試，說成全站已獲證實的改善。