Service Worker 快取和 HTTP 快取

在服務工作者快取和 HTTP 快取層中使用一致或不同的到期邏輯的優缺點。

雖然服務工作者和 PWA 已成為現代網路應用程式的標準,但資源快取功能卻變得比以往更為複雜。本文將概略說明瀏覽器快取,包括:

  • 服務工作者快取和 HTTP 快取的用途和差異。
  • 比較不同服務工作者快取到期策略與一般 HTTP 快取策略的優缺點。

大致來說,瀏覽器在要求資源時,會依照下列快取順序進行:

  1. 服務工作者快取:服務工作者會檢查資源是否位於快取中,並根據程式設計的快取策略決定是否要傳回資源本身。請注意,系統不會自動執行這項作業。您需要在服務工作站中建立擷取事件處理常式,並攔截網路要求,以便從服務工作站的快取,而非網路提供要求。
  2. HTTP 快取 (也稱為瀏覽器快取):如果資源位於 HTTP 快取中且尚未過期,瀏覽器會自動使用 HTTP 快取中的資源。
  3. 伺服器端:如果服務工作者快取或 HTTP 快取中沒有任何內容,瀏覽器會連線至網路來要求資源。如果資源未在 CDN 中快取,要求就必須一路返回原始伺服器。

快取流程

快取圖層

Service Worker 快取

服務工作站會攔截網路類型的 HTTP 要求,並使用快取策略來判斷應傳回哪些資源給瀏覽器。服務工作者快取和 HTTP 快取的一般用途相同,但服務工作者快取提供更多快取功能,例如精細控制快取的內容和快取方式。

控管服務工作者快取

服務工作者會使用事件監聽器 (通常是 fetch 事件) 攔截 HTTP 要求。以下程式碼片段示範快取優先快取策略的邏輯。

圖表:服務工作者如何攔截 HTTP 要求

強烈建議您使用 Workbox,避免重複開發。舉例來說,您可以使用單行規則運算式程式碼註冊資源網址路徑

import {registerRoute} from 'workbox-routing';

registerRoute(new RegExp('styles/.*\\.css'), callbackHandler);

服務工作者快取策略和用途

下表列出常見的服務工作者快取策略,以及每個策略的適用時機。

策略 更新間隔的理由 用途
僅限網路 內容必須隨時保持最新狀態。
  • 付款和結帳
  • 餘額報表
網路回復使用快取 建議您提供最新內容。不過,如果網路發生故障或不穩定,則可放送稍舊的內容。
  • 及時資料
  • 價格和費率 (需要免責事項)
  • 訂單狀態
Stale-while-revalidate 您可以立即提供快取內容,但日後應使用更新版的快取內容。
  • 新聞動態
  • 產品資訊頁面
  • 訊息
先使用快取,再改用網路 內容非關重要,可從快取中提供,以提升效能,但服務工作者應不時檢查更新。
  • 應用程式命令介面
  • 共同資源
僅快取 內容幾乎不會變更。
  • 靜態內容

服務工作者快取的其他優點

除了可精細控制快取邏輯,服務工作者快取功能還提供以下功能:

  • 為來源提供更多記憶體和儲存空間:瀏覽器會根據每個來源分配 HTTP 快取資源。換句話說,如果您有多個子網域,這些子網域都會共用相同的 HTTP 快取。我們無法保證來源/網域的內容會長時間保留在 HTTP 快取中。舉例來說,使用者可以透過瀏覽器設定 UI 手動清除快取,或是在頁面上觸發強制重新載入。使用服務工作者快取功能,快取的內容就更有可能持續保留在快取中。詳情請參閱「永久性儲存空間」。
  • 在網路不穩定或離線情況下,提供更彈性的彈性:使用 HTTP 快取時,您只能選擇要不要快取資源。透過服務工作者快取,您可以更輕鬆地減輕小型「中斷」情形 (採用「stale-while-revalidate」策略),提供完整的離線體驗 (採用「Cache only」策略),甚至是介於兩者之間的某些內容,例如自訂 UI,其中部分網頁內容來自服務工作者快取,並在適當情況下排除部分內容 (採用「Set catch handler」策略)。

HTTP 快取

瀏覽器首次載入網頁和相關資源時,會將這些資源儲存在 HTTP 快取中。除非使用者明確停用,否則瀏覽器通常會自動啟用 HTTP 快取。

使用 HTTP 快取功能,表示您必須依賴伺服器來決定快取資源的時間和時間長度。

使用 HTTP 回應標頭控制 HTTP 快取到期時間

當伺服器回應瀏覽器對資源的要求時,伺服器會使用 HTTP 回應標頭,告知瀏覽器應快取資源多久。詳情請參閱「回應標頭:設定網路伺服器」。

HTTP 快取策略和用途

HTTP 快取比服務工作者快取簡單許多,因為 HTTP 快取只處理以時間為準 (TTL) 的資源到期邏輯。如要進一步瞭解 HTTP 快取策略,請參閱「應使用哪些回應標頭值?」和「摘要」。

設計快取到期邏輯

本節將說明在服務工作者快取和 HTTP 快取層中使用一致的到期日邏輯的優缺點,以及在這些層中使用個別到期日邏輯的優缺點。

下方的 Glitch 示範如何在不同情境下,使用服務工作者快取和 HTTP 快取功能:

所有快取層的一致到期邏輯

為了說明優缺點,我們將探討 3 種情境:長期、中期和短期。

情境 長期快取 中期快取 短期快取
Service worker 快取策略 快取,改用網路 Stale-while-revalidate 網路改用快取
服務工作者快取 TTL 30 天 1 天 10 分鐘
HTTP 快取 max-age 30 天 1 天 10 分鐘

情境:長期快取 (快取,改用網路)

  • 快取資源有效 (30 天以下):服務工作者會立即傳回快取的資源,不必連線。
  • 快取資源到期 (超過 30 天):服務工作站會前往網路擷取資源。瀏覽器的 HTTP 快取中沒有資源的副本,因此會向伺服器端要求資源。

缺點:在這種情況下,由於瀏覽器會在快取在 Service Worker 中到期時,一律將要求傳遞至伺服器端,因此 HTTP 快取的價值較低。

情境:中期快取 (Stale-while-revalidate)

  • 快取資源有效時 (< 1 天):服務工作者會立即傳回快取的資源,並前往網路擷取資源。瀏覽器在 HTTP 快取中擁有資源的副本,因此會將該副本傳回服務工作站。
  • 快取資源到期 (超過 1 天):服務工作站會立即傳回快取的資源,並前往網路擷取資源。瀏覽器在 HTTP 快取中沒有資源的副本,因此會前往伺服器端擷取資源。

缺點:Service Worker 需要額外的快取破壞機制,才能覆寫 HTTP 快取,充分利用「重新驗證」步驟。

情境:短期快取 (網路改用快取)

  • 快取資源有效時 (10 分鐘內):服務工作站會前往網路擷取資源。瀏覽器在 HTTP 快取中擁有資源的副本,因此可將該副本傳回服務工作站,而無須經過伺服器端。
  • 快取資源到期 (超過 10 分鐘):服務工作站會立即傳回快取的資源,並前往網路擷取資源。瀏覽器在 HTTP 快取中沒有資源的副本,因此會前往伺服器端擷取資源。

缺點:與中期快取情境類似,服務工作站需要額外的快取破壞邏輯,才能覆寫 HTTP 快取,從伺服器端擷取最新資源。

服務工作者可用於所有情況

在所有情況下,服務工作者快取在網路不穩定時仍可傳回快取資源。另一方面,當網路不穩定或中斷時,HTTP 快取就無法正常運作。

服務工作者快取和 HTTP 層級的快取到期邏輯不同

為了說明優缺點,我們將再次探討長期、中期和短期的情況。

情境 長期快取 中期快取 短期快取
Service worker 快取策略 快取,改用網路 Stale-while-revalidate 網路改用快取
服務工作者快取 TTL 90 天 30 天 1 天
HTTP 快取 max-age 30 天 1 天 10 分鐘

情境:長期快取 (快取,改用網路)

  • 快取的資源在 Service Worker 快取中有效 (90 天以下):Service Worker 會立即傳回快取的資源。
  • 服務工作站快取資源在快取中過期 (超過 90 天):服務工作站會前往網路擷取資源。瀏覽器的 HTTP 快取中沒有資源的副本,因此會轉至伺服器端。

優缺點:

  • 優點:服務工作者會立即傳回快取的資源,因此使用者可立即獲得回應。
  • 優點:服務工作者可更精細地控管何時使用快取,以及何時要求新版資源。
  • 缺點:必須採用明確的服務工作者快取策略。

情境:中期快取 (Stale-while-revalidate)

  • 快取的資源在 Service Worker 快取中有效 (30 天以下):Service Worker 會立即傳回快取的資源。
  • 服務 worker 快取快取資源的快取期限已過期 (超過 30 天):服務 worker 會前往網路取得資源。瀏覽器的 HTTP 快取中沒有資源的副本,因此會轉交至伺服器端。

優缺點:

  • 優點:服務工作者會立即傳回快取的資源,因此使用者可立即獲得回應。
  • 優點:服務工作者可確保指定網址的下一個要求使用來自網路的新回應,這要歸功於「在背景」執行的重新驗證作業。
  • 缺點:必須採用明確的服務工作者快取策略。

情境:短期快取 (網路改用快取)

  • 快取的資源在服務工作站快取中有效 (<= 1 天):服務工作站會前往網路取得資源。如果 HTTP 快取中有資源,瀏覽器會傳回該資源。如果網路發生問題,服務工作站會從服務工作站快取傳回資源
  • 服務工作站快取資源在快取記憶體中到期 (超過 1 天):服務工作站會前往網路擷取資源。由於 HTTP 快取中的快取版本已過期,瀏覽器會透過網路擷取資源。

優缺點:

  • 優點:當網路不穩定或中斷時,服務工作站會立即傳回快取的資源。
  • 缺點:服務工作站需要額外的快取破壞機制,才能覆寫 HTTP 快取並提出「網路優先」要求。

結論

由於快取情境組合的複雜性,我們無法設計一項涵蓋所有情況的規則。不過,根據前面各節的發現結果,設計快取策略時,請參考以下幾項建議:

  • 服務工作者快取邏輯不必與 HTTP 快取到期邏輯一致。盡可能在服務工作站中使用較長的到期邏輯,以便讓服務工作站享有更多控制權。
  • HTTP 快取仍扮演重要角色,但在網路不穩定或中斷時,就無法可靠。
  • 請重新檢視各項資源的快取策略,確保服務工作單元快取策略可提供其價值,且不會與 HTTP 快取衝突。

瞭解詳情