肚子餓的客人在路上打開菜單，畫面卻只有一個轉圈。對店家來說，這不是小小的技術瑕疵，而是顧客還沒看到商品就離開的入口問題。但慢一秒究竟少賺多少，不能直接套一個神奇百分比。
Google 數字怎麼看？不要把歷史研究變成保證
Google 引用的2016 年行動網站樣本指出，載入超過三秒時，約 53% 的造訪會被放棄。這說明等待值得重視，但不是今天每個台灣餐廳的固定流失率，也不代表每慢一秒就一定少相同比例的營收。
真正的損失可用店內數據估計：假設每月 10,000 次有效造訪、轉換率 2%、客單 400 元，營收為 80,000 元；若其他條件相近，實測優化後轉換率達 2.4%，增加 40 筆訂單、16,000 元營收。這是示範試算，不是效能改善的必然成果，增加利潤還要扣食材、金流與履約成本。
手機版才是菜單真正的戰場
辦公室 Wi-Fi 與高階筆電很容易掩蓋問題。顧客可能在捷運出口、訊號不穩的騎樓，以中階手機使用 4G 或 5G；行動網路名稱並不保證每次連線都快。首屏應先出現店名、主要分類、餐點與行動按鈕，不要讓大型開場影片擋住菜單。
分開量測第一次開啟、回訪、加入購物車與跳到金流的速度。只有首頁分數漂亮，結帳仍卡住，生意不會因此受益。
網站為什麼會慢？先查瓶頸再花錢升級
- 圖片：把相機原檔直接丟上去，手機也下載數千像素照片。
- 腳本：聊天、廣告追蹤、輪播與外掛各自載入大型程式。
- 資料：每次開菜單都重查相同內容，API 或資料庫回應過慢。
- 主機：資源不足、距離過遠或部署設定不當。
先看網路請求與效能紀錄，確認時間花在下載、伺服器等待還是主執行緒。單純換更貴的主機，救不了每張 8 MB 的菜單照片。
工程師的優化順序：先讓客人看見並能操作
圖片與程式各減一點負擔
依顯示尺寸輸出 WebP／AVIF 與適當畫質，指定圖片尺寸避免跳版；首屏主要圖片優先載入，下面的圖片再延後。Code Splitting 把非必要互動拆開，使用者進入需要的畫面時才下載，並清理沒有實際用途的外掛。
快取與 CDN 要保留資料正確性
CDN 可就近提供圖片與靜態內容，伺服器快取可減少重複工作；會員、購物車與訂單不能用共用快取洩漏。菜單售完、價格與可接單時段需要更新機制，結帳仍應由伺服器重新驗證。快速顯示過期價格，最後一樣會造成棄單。
驗收不只看跑分，還要看完成訂單
Google 的良好 Core Web Vitals 門檻包含LCP ≤ 2.5 秒、INP ≤ 200 毫秒、CLS ≤ 0.1，以真實使用體驗的第 75 百分位檢視。LCP 看主要內容何時出現，INP 看操作回應，CLS 看版面是否亂跳；它們不等同整頁下載完成時間。
用 PageSpeed Insights 找改善方向，再以真實手機與 GA4 漏斗看商品瀏覽、加入購物車、開始結帳與完成購買。控制活動、流量來源與商品供應差異，才能判斷改善是否帶來商業效果。
店家可以立刻做的檢查
- 用行動網路測首頁、菜單與結帳。
- 優先處理最大圖片與阻塞操作的腳本。
- 設定正確快取範圍與菜單更新方式。
- 同時比較真實效能、轉換率與每單貢獻。
下一步：把問題變成可執行的改善
你的網站讓客人快速選餐，還是讓他盯著空白畫面？先提供網址與最重要的交易流程，我們可以從品牌官網與視覺設計服務評估效能卡點，把等待變成可以執行的改善清單。
了解品牌官網與視覺設計，或到聯絡頁提供目前流程與需求。實際功能、第三方支援、費用及交付範圍依評估與合約確認。
延伸閱讀
參考資料與試算說明
資料查閱日期：2026 年 10 月 17 日。情境數字用於說明計算方法，不是客戶成效、服務報價或收益保證；圖片為服務概念示意。