Service Worker 快取和 HTTP 快取

在 Service Worker 快取和 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);

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

下表概述了常見的 Service Worker 快取策略，以及每項策略的實用時機。

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

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

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

HTTP 快取

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

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

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

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

HTTP 快取策略和用途

HTTP 快取比 Service Worker 快取簡單許多，因為 HTTP 快取只會處理以時間為基礎的 (TTL) 資源到期時間邏輯。如要進一步瞭解 HTTP 快取策略，請參閱「應使用哪些回應標頭值？」和「摘要」。

設計快取到期邏輯

本節說明在 Service Worker 快取和 HTTP 快取層使用一致到期邏輯的優缺點，以及這些層中個別到期邏輯的優缺點。

以下 Glitch 示範 Service Worker 快取和 HTTP 快取在不同情境下的運作方式：

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

為示範優缺點，我們將探討以下 3 種情境：長期、中期和短期。

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

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

缺點：在這種情況下，HTTP 快取提供的值較少，因為當服務工作站中的快取到期時，瀏覽器一律會將要求傳送至伺服器端。

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

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

缺點：Service Worker 需要額外的快取清除功能來覆寫 HTTP 快取，以便充分利用「重新驗證」步驟。

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

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

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

適用所有情境的 Service Worker

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

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

為示範優缺點，我們將再次探討長期、中期和短期的情境。

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

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

優缺點：

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

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

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

優缺點：

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

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

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

優缺點：

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

結論

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

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

瞭解詳情

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