在 Service Worker 快取和 HTTP 快取層之間,使用一致或不同的到期邏輯的優缺點。
雖然服務工作人員和 PWA 正在成為現代網路應用程式的標準,但資源快取比以往更加複雜。本文將介紹瀏覽器快取的大方向,包括:
- 服務工作站快取和 HTTP 快取的使用案例和差異。
- 比較不同 Service Worker 快取到期策略與一般 HTTP 快取策略的優缺點。
快取流程總覽
大致來說,瀏覽器要求資源時,會依下列快取順序執行操作:
- 服務工作人員快取:服務工作人員會檢查資源是否位於快取中,並根據程式設計的快取策略,決定是否傳回資源本身。請注意,這項作業不會自動執行。您需要在服務工作人員中建立擷取事件處理常式,並攔截網路要求,以便從服務工作人員的快取而非網路提供要求。
- HTTP 快取 (也稱為瀏覽器快取):如果系統在 HTTP 快取中找到資源,且資源尚未過期,瀏覽器就會自動使用 HTTP 快取中的資源。
- 伺服器端:如果服務工作人員快取或 HTTP 快取中沒有任何內容,瀏覽器會前往網路要求資源。如果 CDN 中沒有快取資源,要求就必須一路傳回原始伺服器。
快取層
Service Worker 快取
服務工作站會攔截網路類型的 HTTP 要求,並使用快取策略判斷應傳回瀏覽器的資源。服務工作人員快取和 HTTP 快取的一般用途相同,但服務工作人員快取提供更多快取功能,例如精細控制要快取的內容和快取方式。
控管 Service Worker 快取
服務工作人員會使用事件監聽器 (通常是 fetch
事件) 攔截 HTTP 要求。這個程式碼片段示範了「快取優先」快取策略的邏輯。
強烈建議使用 Workbox,避免重複發明輪子。舉例來說,您可以使用單行規則運算式程式碼註冊資源網址路徑。
import {registerRoute} from 'workbox-routing';
registerRoute(new RegExp('styles/.*\\.css'), callbackHandler);
Service worker 快取策略和用途
下表列出常見的 Service Worker 快取策略,以及每種策略的適用時機。
策略 | 更新間隔理由 | 用途 |
---|---|---|
僅限網路 | 內容必須隨時保持最新狀態。 |
|
網路 回復為快取 | 建議提供最新內容。不過,如果網路連線失敗或不穩定,放送稍微舊的內容也是可以接受的。 |
|
Stale-while-revalidate | 立即提供快取內容沒問題,但日後應使用更新後的快取內容。 |
|
先從快取載入,再從網路載入 | 內容並非重要,可從快取提供以提升效能,但服務工作人員應偶爾檢查更新。 |
|
僅限快取 | 內容很少變更。 |
|
Service Worker 快取功能的其他優點
除了精細控制快取邏輯外,服務工作人員快取還提供下列功能:
- 為來源提供更多記憶體和儲存空間:瀏覽器會根據來源分配 HTTP 快取資源。換句話說,如果您有多個子網域,這些子網域都會共用相同的 HTTP 快取。無法保證來源/網域的內容會長期保留在 HTTP 快取中。舉例來說,使用者可以透過瀏覽器的設定使用者介面手動清除快取,或在網頁上觸發強制重新載入。使用 Service Worker 快取時,快取內容較有可能維持快取狀態。詳情請參閱「永久儲存空間」。
- 在網路不穩或離線時,提供更高的彈性:使用 HTTP 快取時,您只有二元選擇:資源是否要快取。透過 Service Worker 快取,您可以更輕鬆地減輕小「故障」的影響 (使用「過時時重新驗證」策略)、提供完整的離線體驗 (使用「僅限快取」策略),甚至介於兩者之間,例如自訂 UI,頁面部分內容來自 Service Worker 快取,部分內容則排除在外 (使用「設定擷取處理常式」策略),視情況而定。
HTTP 快取
瀏覽器首次載入網頁和相關資源時,會將這些資源儲存在 HTTP 快取中。除非使用者明確停用,否則瀏覽器通常會自動啟用 HTTP 快取。
使用 HTTP 快取表示要依賴伺服器判斷資源的快取時間和快取時間長度。
使用 HTTP 回應標頭控制 HTTP 快取到期時間
當伺服器回應瀏覽器對資源的要求時,伺服器會使用 HTTP 回應標頭,告知瀏覽器應快取資源的時間長度。詳情請參閱「回應標頭:設定網路伺服器」。
HTTP 快取策略和用途
HTTP 快取比 Service Worker 快取簡單許多,因為 HTTP 快取只處理以時間為準 (TTL) 的資源到期邏輯。如要進一步瞭解 HTTP 快取策略,請參閱「您應該使用哪些回應標頭值?」和「摘要」。
設計快取到期邏輯
本節說明在 Service Worker 快取和 HTTP 快取層使用一致的到期邏輯,以及在這些層使用個別到期邏輯的優缺點。
所有快取層的有效期限邏輯一致
為說明優缺點,我們將探討 3 種情境:長期、中期和短期。
情境 | 長期快取 | 中期快取 | 短期快取 |
---|---|---|---|
Service worker 快取策略 | 快取,改用網路 | Stale-while-revalidate | 網路回溯至快取 |
Service Worker 快取 TTL | 30 天 | 1 天 | 10 分鐘 |
HTTP 快取 max-age | 30 天 | 1 天 | 10 分鐘 |
情境:長期快取 (快取,回溯至網路)
- 快取資源有效 (<= 30 天):服務工作人員會立即傳回快取資源,不會連上網路。
- 快取資源過期 (超過 30 天):服務工作站會前往網路擷取資源。瀏覽器的 HTTP 快取中沒有資源副本,因此會前往伺服器端尋找資源。
缺點:在這種情況下,HTTP 快取提供的價值較低,因為當服務工作人員中的快取過期時,瀏覽器一律會將要求傳遞至伺服器端。
情境:中長期快取 (Stale-while-revalidate)
- 快取資源有效 (<= 1 天):服務工作人員會立即傳回快取資源,並前往網路擷取資源。瀏覽器的 HTTP 快取中有資源副本,因此會將該副本傳回給服務工作人員。
- 快取資源過期 (超過 1 天):服務工作人員會立即傳回快取資源,並前往網路擷取資源。瀏覽器的 HTTP 快取中沒有資源副本,因此會前往伺服器端擷取資源。
缺點:Service Worker 需要額外的快取清除作業,才能覆寫 HTTP 快取,盡量發揮「重新驗證」步驟的效益。
情境:短期快取 (網路回復為快取)
- 快取資源有效 (<= 10 分鐘):服務工作人員會前往網路擷取資源。瀏覽器的 HTTP 快取中有資源副本,因此會將該副本傳回服務工作人員,而不會前往伺服器端。
- 快取資源過期 (超過 10 分鐘):服務工作人員會立即傳回快取資源,並前往網路擷取資源。瀏覽器的 HTTP 快取中沒有資源副本,因此會前往伺服器端擷取資源。
缺點:與中期快取情境類似,服務工作人員需要額外的快取清除邏輯來覆寫 HTTP 快取,才能從伺服器端擷取最新資源。
所有情境中的 Service Worker
在所有情境中,網路不穩定時,服務工作人員快取仍可傳回快取資源。另一方面,如果網路不穩定或中斷,HTTP 快取就不可靠。
服務工作站快取和 HTTP 層的快取到期邏輯不同
為說明優缺點,我們將再次探討長期、中期和短期情境。
情境 | 長期快取 | 中期快取 | 短期快取 |
---|---|---|---|
Service worker 快取策略 | 快取,改用網路 | Stale-while-revalidate | 網路回溯至快取 |
Service Worker 快取 TTL | 90 天 | 30 天 | 1 天 |
HTTP 快取 max-age | 30 天 | 1 天 | 10 分鐘 |
情境:長期快取 (快取,回溯至網路)
- 快取資源在 Service Worker 快取中有效 (<= 90 天):Service Worker 會立即傳回快取資源。
- 服務工作人員快取中的快取資源過期 (超過 90 天):服務工作人員會前往網路擷取資源。瀏覽器的 HTTP 快取中沒有資源副本,因此會前往伺服器端。
優缺點:
- 優點:服務工作人員會立即傳回快取資源,因此使用者會感受到即時回應。
- 優點:服務工作人員可更精細地控制何時使用快取,以及何時要求新版資源。
- 缺點:必須制定明確的 Service Worker 快取策略。
情境:中期快取 (Stale-while-revalidate)
- 如果快取資源在 Service Worker 快取中有效 (<= 30 天):Service Worker 會立即傳回快取資源。
- 服務工作站快取中的快取資源過期 (超過 30 天):服務工作站會前往網路尋找資源。瀏覽器的 HTTP 快取中沒有資源副本,因此會前往伺服器端。
優缺點:
- 優點:服務工作人員會立即傳回快取資源,因此使用者會感受到即時回應。
- 優點:服務工作人員可確保特定網址的下一個要求使用來自網路的最新回應,這要歸功於「在背景」進行的重新驗證。
- 缺點:必須制定明確的 Service Worker 快取策略。
情境:短期快取 (網路回復為快取)
- 快取資源在服務工作站快取中有效 (<= 1 天):服務工作站會前往網路尋找資源。如果 HTTP 快取中有資源,瀏覽器就會傳回該資源。如果網路中斷,服務工作人員會從服務工作人員快取傳回資源
- 服務工作站快取中的快取資源過期 (超過 1 天):服務工作站會前往網路擷取資源。由於 HTTP 快取中的快取版本已過期,瀏覽器會透過網路擷取資源。
優缺點:
- 優點:網路不穩定或中斷時,服務工作人員會立即傳回快取資源。
- 缺點:服務工作人員需要額外的快取清除作業,才能覆寫 HTTP 快取並發出「網路優先」要求。
結論
由於快取情境的組合相當複雜,因此無法設計一項涵蓋所有情況的規則。不過,根據前幾節的發現,設計快取策略時,有幾項建議可供參考:
- 服務工作人員快取邏輯不需與 HTTP 快取到期邏輯一致。如有可能,請在 Service Worker 中使用較長的到期邏輯,授予 Service Worker 更多控制權。
- HTTP 快取仍扮演重要角色,但網路不穩定或中斷時,就不可靠了。
- 重新檢視各項資源的快取策略,確保服務工作人員快取策略能提供價值,且不會與 HTTP 快取衝突。