Service Worker 快取和 HTTP 快取

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

Jonathan Chen

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

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

快取流程總覽

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

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

快取圖層

Service Worker 快取

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

控管服務工作者快取

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

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

import {registerRoute} from 'workbox-routing';

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

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

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

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

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

• 為來源提供更多記憶體和儲存空間：瀏覽器會根據每個來源分配 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 種情境：長期、中期和短期。

情境：長期快取 (快取，改用網路)

• 快取資源有效 (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 快取中有效 (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 快取衝突。

瞭解詳情

• 網路可靠性
• 透過 HTTP 快取防止不必要的網路要求
• HTTP 快取程式碼研究室
• 評估服務工作者對實際效能的影響
• Cache-Control 與 Expires
• 揭開快取的神秘面紗：檢查、清除及停用快取