GitHub Issues 把等待搬到背景
GitHub 重新設計 Issues 的前端導覽架構，目標不是讓後端憑空變快，而是少等幾次網路。它用 IndexedDB、記憶體快取、predictive prefetching、service worker 與 stale-while-revalidate，把看過或可能用到的資料先留在瀏覽器。使用者切換 Issue、列表及相關頁面時，可先看到本地資料，再於背景同步新版內容；即時完成的導覽比例也從 4% 提升到 22%。
現實應用
這套做法很適合 GitHub Issues 這種讀取頻繁、資料關聯相對明確，而且使用者會反覆往返的工作介面。客服工單、專案管理、文件系統、後台列表與企業內部工具，都能借鏡「先顯示 shell、命中快取後補資料」的模式。對每天切換大量項目的開發者來說，省下的不只幾百毫秒，也能減少等待造成的思緒中斷。
期望評估
我認為低標期望，是讓重複造訪的頁面穩定少等一次 API，並改善整體延遲分布。GitHub 的 P10 約從 600ms 降到 70ms、P25 從 800ms 降到 120ms，中位數也由 1,200ms 降至 700ms。
我猜高標可以做到接近桌面 App 的切頁手感，尤其在網路不穩時更有感。不過尾端改善有限：P90 只由 2,400ms 降至 2,100ms，代表首次載入、快取未命中及後端慢請求仍然存在。
商業策略分析
受影響最大的會是大型 SaaS、協作工具與開發平台。當功能差異逐漸縮小，操作是否「跟得上思考」就會變成留存與付費體驗的一部分。我認為值得跟進的不是照抄 prefetch，而是先找出高頻導覽路徑，再投資可量測的本地快取架構。若產品資料圖很大、寫入衝突多，預抓後落地仍得重抓，成本可能高過收益。
實作細節
請求先由 service worker 攔截：有可用資料就直接回傳並在背景更新；沒有或已不適用才走正常後端路徑。IndexedDB 負責跨工作階段保存，記憶體快取服務當次操作，preheating 則依導覽模式預先填入可能需要的資料。已知取捨是畫面可能先顯示稍舊內容，因此介面必須妥善處理同步更新與讀寫衝突。