一、數位便利還是數位災難？
我平常都會去咖啡店，路易莎常常是我的首選，因為便宜、好喝、又有充座讓我辦公，但是我用手機點餐，網頁卡到爆炸，我常常要花 5 分鐘以上才能點好一杯飲料，有些門市有自己的平板點餐系統，線上付款完後，會給號碼單，上面有 QR code 可查詢出餐狀態，出餐狀態仍是製餐中，顧客不知道店家是否完成餐點，店員喊得半死沒人領餐。我就在想以下幾件事：
- 什麼讓路易莎點餐系統變慢了？
- 路易莎點餐流程出了什麼狀況？
- 路易莎哪一塊沒有把控好？解決方案是什麼？
圖一、路易莎咖啡
二、為什麼網頁會 load 這麼慢？
網頁會卡不光只是網路問題，而是「發送資料」與「手機硬體極限」的正面碰撞。
1. 網路連線的併發災難：450 個請求
光路易莎單一個點餐頁面會觸發 450 個 HTTP 請求，其中150 個 request 是圖片，在 100 Mbps 網速的電腦版花費 35 秒才全部 load 完，如圖二所示，這些請求是跟伺服器要資料的，HTTP Archive 在 2024 年發布的 《Web Almanac》 報告，中位數請求數： 2024 年行動版網頁則為 66 個 [1]，他們請求數是這份報告中位數 6 倍不止。
通常 Http 請求也並非一次打出去，而是佇列方式打，6個請求為一組向伺服器併發，第 7 個以後排隊等候下一輪[2]。試想一下如果手機在低網速，要看到餐點內容要花多久？
圖二、網頁請求
2. 操作卡頓元兇之一：記憶體分配
瀏覽器背後的 JavaScript 引擎將記憶體分為「新生代」與「舊生代」[8]。在手機端，負責存放新產生、短命物件的新生代空間極其有限。當數百個併發請求瞬間產生數千個 Promise 與資料物件時，會極速填滿這塊空間。
這迫使引擎必須高頻率啟動 GC (垃圾回收) 機制來清理記憶體。雖然單次清理極快，但在極短時間內連續觸發，這種微小的執行暫停（Stop-the-world）累積起來，便成了用戶感官上的明顯卡頓。
此外，手機系統並不像 PC 有虛擬記憶體機制，記憶體用滿了並不會拿硬碟來遞補[5][6]，等於說記憶體資源是珍貴的、分配要是嚴苛。WebView 作為運行在 Line 內部的獨立進程，在系統資源分配的優先權上天生弱於宿主 App。當記憶體水位過高時，系統為了保證 Line 本身的穩定，會嚴格限制 WebView 的資源調度，甚至直接導致崩潰或白屏。
3. 渲染瓶頸：為什麼快速滑動會看到白塊？
現代瀏覽器瀏覽器為了節省效能，會將長網頁切成一格格的「磁貼（Tiles）」，當你滑動的才會載入該磁貼內容[3][4]。
渲染空窗期： 若手機處理器正忙於處理複雜運算（例如垃圾回收 GC、或背景其他程式搶佔資源），導致繪製速度跟不上手指滑動的速度時，瀏覽器為了維持滑動的流暢感，會被迫先顯示預設的白色底圖（圖三），等計算完成後，餐點內容才會「跳」出來。
圖三、點餐網頁頁面部分空白
三、平板端：無效流程、交易失敗處理
1. 無效的狀態機器：
店面忙碌時，店員引導顧客使用平板點餐以緩解人力壓力，但系統設計卻反過來成了營運累贅。
出餐資訊不對稱：門市店員在店面忙碌情況會要求顧客優先操作平板點餐，線上付款的顧客並沒有呼叫器，只有 QR code 掃描的網頁可以追蹤出餐進度，店員不會去更新狀態，形成線上線下脫節。
店員變人肉廣播：顧客也不知道到底出餐怎麼樣，全憑店員喊得半死叫顧客取餐，這種數位化不僅沒減輕勞動，反而增加了溝通的無效摩擦。
2. 扣款成功卻沒有結帳：
我有一次去某一家門市，操作平板的時候進入結帳環節，刷卡完也確定扣帳，又跳回選擇支付方式頁面，畫面顯示與主機失去連線，店員跟我說我沒有結到帳，要求我 show 出信用卡扣款畫面，造道理主機失去連線後交易也要跟著失敗，而非扣款成功但是卻沒結帳，違反交易元子性[7]。
3. 資安疑慮：QR code 掃描的叫號網頁是沒有掛憑證的（圖四），也就說網頁是明碼傳輸，萬一裡面有重要個資直接就被竊聽了。
圖四、未加密叫號網頁
四、商業批判與解決方案
從路易莎的系統現況，我們能看到企業數位轉型最常見的三大負債：
1. 為了經營數據，犧牲了消費者體驗：將會員到整合 Line 、你訂這些平台對企業來說是好事，方便分析客群，但是沒有認真做系統驗收（SLA），例如：手機裝置上延遲、交易錯誤率等等。
2. 員工與系統之間流程矛盾：線上支付的顧客要拿到餐點全憑顧客有沒有乖乖待在原地、或是自己有沒有注意到，網頁的狀態根本是裝飾。線上點餐本身是加速點餐速度、店員可以專注製作餐點，但是變相變成店員要找顧客取餐，將櫃檯的排隊壓力轉嫁給了消費者的手機與店員的喉嚨。
3. 品牌價值的隱形流失：路易莎身為咖啡業龍頭，若能忍受這樣消費者體驗、系統架構，真的是在透支顧客的品牌忠誠度，顧客容易因為體驗更換品牌、降低牌品忠誠度，哪天殺出一個像是瑞幸 (luckin)的咖啡品牌，挾帶更優質的基礎設施殺入市場，那就得不償失。
我認為優化策略分短、長期：
短期策略： 應要求供應商執行 API 聚合 (Aggregation) 與 懶加載 (Lazy Loading)，不要一次菜單全 load 進來。
長期展望： 路易莎應重新訂定數位驗收標準。數位轉型不應只是「有功能」，更要看「效能指標」與「異常處理能力」。
作為老主顧，我希望路易莎能經營長長久久。
參考資源
[1] https://almanac.httparchive.org/en/2024/page-weight
[2] https://dev.to/sibiraj/understanding-http2-parallel-requests-streams-vs-connections-3anf
[3] https://www.chromium.org/developers/design-documents/impl-side-painting/
[4] https://developer.chrome.com/blog/inside-browser-part3
[6] https://developer.android.com/topic/performance/memory-management
[7] https://zh.wikipedia.org/zh-tw/ACID
