什麼是用戶端儲存 (Client-side storage)
對一個 App 來說,為了達到某些目的,將相關資料存在用戶端是相對方便的,舉例來說
- 個人偏好設定,像是常用功能、顏色主題、字體大小
- 將前一次操作快取,像是紀錄購物車資料或是線上編輯器在斷線時先暫時將資料保存
- 不常改變的資料或靜態資源快取
- 離線操作所需要的檔案
通常用戶端的儲存和伺服器端的儲存會是一起搭配使用的,舉例來說當我們使用影音串流功能時,會從伺服器端下載相關資料到用戶端使用,在過程中 App 也能夠將資料快取起來以便下次使用。
不過在實務上,瀏覽器用戶端的儲存目前有各式解決方案,也都有著各自的限制存在,如果是有大小限制的儲存,就必須注意定時和伺服器端同步去避免資料遺失。
常見用戶端儲存機制介紹
目前常見的用戶端儲存機制如下:
- Cookies: 每次發 Request 都會一起送出,所以要大小控制要注意
- Web Storage API
- SessionStorage: 同步阻塞 (synchronous),上限 5MB,僅存在於 Tab 當次操作,無法被 web workers 或 service workers 使用
- LocalStorage: 同步阻塞 (synchronous),上限 5MB,無法被 web workers 或 service workers 使用
- Cache API: 非同步,較適合跟網路請求相關的靜態資源快取
- IndexedDB API: 非同步,適合儲存程式邏輯相關資料,使用上相對複雜,較推薦使用像是 idb 這類相關套件操作
- WebSQL: 不建議使用
用戶端儲存限制
一般來說儲存空間的上限如下:
- Chrome 總共最多可以用到 80% 的硬碟,每個網域最高是 60%
- IE 系列 10 以後最多 250MB
- Firefox 硬碟空間的 50%
- Safari 1GB
在 Chrome、Firefox、Edge 等瀏覽器中可以使用以下的程式碼去估計剩餘空間:
https://caniuse.com/mdn-api_storagemanager
1 | if (navigator.storage && navigator.storage.estimate) { |
QuotaExceededError 錯誤處理
- IndexedDB
1 | const transaction = idb.transaction(["entries"], "readwrite"); |
- Cache API
1 | try { |
儲存淘汰機制 (eviction)
資料在儲存上會分成兩種類別
- Best Effort: 當瀏覽器空間不足,會開始執行淘汰機制
- Chromium: 從最少使用的開始,會自動清除資料且不會通知用戶
- Firefox: 從最少使用的開始,會自動清除資料且不會通知用戶
- Internet Explorer 10+ 不會清除,但會停止寫入
- Persistent: 不會被自動清除
LRU policy
當硬碟空間即將用完時,瀏覽器會依據 LRU policy (least recently used) 的規則透過去清除快取檔案。
- 目前沒有使用的網頁 (tabs/apps)
- 比對最後存取的時間
Persistent Storage
為了避免資料被儲存淘汰機制處理掉,我們能夠通過程式碼去確認、啟用 Persistent Storage。
1 | // 確認目前儲存空間是否套用 Persistent |
啟用過後底下的儲存皆會受到保護,但要注意啟用後目前尚沒有透過程式停用的方式。
- Cache API
- Cookies
- DOM Storage (Local Storage)
- File System API
- IndexedDB
- Service workers
- App Cache (deprecated)
- WebSQL (deprecated)
離線後備頁面介紹 (offline fallback page)
離線後備頁面提供用戶在網路不穩定的情況下,一個備援的顯示頁面。
在過去的網站大多由伺服器提供,所以斷線的情況下原則上就是什麼都沒有,近幾年 JavaScript 相關的進步以及 SPA 觀念開始盛行後,前端能夠掌握的事情也越來越多,離線後備頁面 (offline fallback page) 一個有名的例子就是 Chrome 在斷線狀態下的小恐龍遊戲。
圖片來源: https://web.dev/ >
離線後備頁面實作
對 Progressive Web App 來說,目前最佳的實作方式就是透過 service worker 搭配 Cache Storage API 來提供用戶最佳的離線操作體驗。
接下來會示範一個簡單的情境,當用戶網路斷線時,會自動開啟離線後備頁面,頁面中一方面提供重試的按鈕,另一方面也透過程式實作當網路恢復時自動連線並切換回正常的頁面。
Google 的這個範例主要會有三個頁面加上 service worker 實作:
- 連線正常的第一頁
- 連線正常的第二頁
- 離線後備頁面
- service worker: 偵測到斷線時會將第一頁或第二頁切換到離線後備頁面
Demo 站台:
https://linyencheng.github.io/pwa-offline-fallback/
原始碼:
https://github.com/LinYenCheng/pwa-offline-fallback/tree/main/docs
service worker 離線後備頁面實作
- 宣告常數
1 | // 這次 Cache 存放的名稱 |
install
: 命名快取空間為CACHE_NAME
並加入OFFLINE_URL
快取,透過self.skipWaiting()
跳過等待重啟生效。
1 | self.addEventListener("install", (event) => { |
activate
: 透過self.clients.claim()
讓 Service Worker 直接生效
1 | self.addEventListener("activate", (event) => { |
fetch
: 遇到連線錯誤則使用CACHE_NAME
中的OFFLINE_URL
的快取
1 | self.addEventListener("fetch", (event) => { |
離線後備頁面
因為是離線後備頁面,所以我們會需要把所有的資源都快取起來,其中最簡單的方式就是將所有需要的東西都用 inline 的方式寫在 html 中,若是想要自己去實作較複雜的快取機制,比較建議取使用 workbox 這套工具。
參考連結:
https://developers.google.com/web/tools/workbox/guides/advanced-recipes#offline_page_only
- 可依照情境使用不同的快取策略:
import {CacheFirst, NetworkFirst, StaleWhileRevalidate} from 'workbox-strategies';
- 文件中有提供範例可參考修改,底下的例子說明怎麼把 mp4 相關資源快取
1 | import { registerRoute } from "workbox-routing"; |
喜歡這篇文章,請幫忙拍拍手喔 🤣