Service Worker 快取和 HTTP 快取

在整個 Service Worker 快取和 HTTP 快取層使用一致或不同到期邏輯的優缺點。

Jonathan Chen

雖然服務工作站和 PWA 已成為現代網頁應用程式的標準，但資源快取功能比以往更加複雜。本文將介紹瀏覽器快取的整體概念，包括：

• Service Worker 快取和 HTTP 快取的用途和差異。
• 與一般 HTTP 快取策略相比，不同服務工作站快取過期策略的優缺點。

快取流程總覽

大致來說，瀏覽器要求資源時，會按照下方的快取順序：

1. Service Worker 快取：服務工作站會確認資源是否位於快取中，並根據其程式化的快取策略決定是否傳回資源。請注意，系統不會自動執行此操作。您必須在服務工作站中建立擷取事件處理常式，並攔截網路要求，這樣要求才能從服務工作站的快取 (而非網路) 提供。
2. HTTP 快取 (也稱為瀏覽器快取)：如果資源在 HTTP 快取中找到且尚未過期，瀏覽器會自動使用 HTTP 快取的資源。
3. 伺服器端：如果在 Service Worker 快取或 HTTP 快取中找不到所需資源，瀏覽器就會前往網路來要求資源。如果 CDN 中並未快取資源，要求必須全數回到原始伺服器。

快取層

Service Worker 快取

Service Worker 會攔截網路類型的 HTTP 要求，並使用快取策略決定要將哪些資源傳回瀏覽器。Service Worker 快取和 HTTP 快取用途與一般用途相同，但服務工作站快取提供更多快取功能，例如精細控管快取內容及快取方式。

控制 Service Worker 快取

Service Worker 會使用事件監聽器 (通常是 fetch 事件) 攔截 HTTP 要求。這個程式碼片段示範快取優先快取策略的邏輯。

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

import {registerRoute} from 'workbox-routing';

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

服務工作站的快取策略與用途

下表概述常見的服務工作站快取策略，以及各策略的適用時機。

Service Worker 快取功能的其他優點

除了精細的快取邏輯控制外，Service Worker 的快取功能還具備以下功能：

• 更多來源的記憶體和儲存空間：瀏覽器會根據「來源」分配 HTTP 快取資源。換句話說，如果您有多個子網域，這些子網域都會共用相同的 HTTP 快取。我們無法保證來源/網域的內容在 HTTP 快取中長期保留。舉例來說，使用者可以從瀏覽器的設定使用者介面手動清除，或是觸發網頁上的強制重新載入，藉此清除快取。使用 Service Worker 快取，快取內容就越有可能保持快取。詳情請參閱永久儲存空間。
• 網路不穩定或離線體驗時更有彈性：使用 HTTP 快取時，您只能選擇二元性別：是否要快取資源，或是否要快取資源。有了 Service Worker 快取功能，您就能更輕鬆地 (採用「stale-while-revalidate」策略) 帶來的小「缺陷」，提供完整的離線體驗 (採用「僅快取」策略)，甚至提供完整的離線體驗，例如自訂使用者介面，其中部分內容來自服務工作站快取，以及視情況排除的某些部分 (透過「設定擷取處理常式」策略)。

HTTP 快取

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

使用 HTTP 快取意味著依賴伺服器判斷何時快取資源及長時間。

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

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

HTTP 快取策略和用途

HTTP 快取比服務工作站快取簡單得多，因為 HTTP 快取只會處理以時間為準 (存留時間) 的資源效期邏輯。如要進一步瞭解 HTTP 快取策略，請參閱您應該使用哪一種回應標頭值？和摘要的相關說明。

設計快取到期邏輯

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

下方的「Glitch」示範了服務工作站快取和 HTTP 快取在不同情境下的運作方式：

所有快取層均採用一致的到期時間邏輯

我們將探討 3 種情境：長期、中期和短期。

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

• 快取資源有效時 (不到 30 天)：Service Worker 會立即傳回快取資源，而不會前往該網路。
• 快取資源過期時 (超過 30 天)：Service Worker 會前往網路擷取資源。瀏覽器的 HTTP 快取中沒有資源副本，因此會在伺服器端存取資源。

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

情境：中期快取 (過時時重新驗證)

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

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

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

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

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

各種情境的 Service Worker

在所有情況下，如果網路不穩定，Service Worker 快取仍可傳回快取資源。另一方面，當網路不穩定或無法使用時，HTTP 快取並不可靠。

Service Worker 快取和 HTTP 層使用不同的快取到期邏輯

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

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

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

優缺點：

• Pro：使用者會在 Service Worker 立即傳回快取資源時，即時獲得回應。
• Pro：Service Worker 能更精細地控管何時使用快取，以及要求新版資源的時機。
• Con：必須定義明確的 Service Worker 快取策略。

情境：中期快取 (過時時重新驗證)

• 如果快取的資源在 Service Worker 快取中有效 (少於 30 天)：服務工作站會立即傳回快取的資源。
• 服務工作站快取中的快取資源過期時 (超過 30 天)：服務工作站會前往資源的網路。瀏覽器的 HTTP 快取中沒有資源副本，因此會在伺服器端存取。

優缺點：

• Pro：使用者會在 Service Worker 立即傳回快取資源時，即時獲得回應。
• Pro：由於「在背景」進行重新驗證，服務工作站可以確保特定網址的 next 要求使用來自網路的即時回應。
• Con：必須定義明確的 Service Worker 快取策略。

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

• 如果快取的資源在 Service Worker 快取中有效 (<= 1 天)：服務工作站會前往資源的網路。如果資源存在，瀏覽器就會從 HTTP 快取傳回資源。如果網路故障，服務工作站會從 Service 工作站快取傳回資源
• 服務工作站快取中的快取資源到期時 (超過 1 天)：服務工作站會前往網路以擷取資源。由於 HTTP 快取中的快取版本過期，瀏覽器會透過網路擷取資源。

優缺點：

• Pro：如果網路不穩定或無法使用，Service Worker 會立即傳回快取資源。
• Con：服務工作站需要額外的快取清除才能覆寫 HTTP 快取，並發出「網路優先」要求。

結論

由於快取情境的組合較為複雜，因此不會設計一個涵蓋所有情況的規則。不過，根據先前各節的發現，在設計快取策略時，以下幾點建議：

• 服務工作站的快取邏輯不需要與 HTTP 快取到期時間的邏輯保持一致。如果可以，請在服務工作站中使用較長的到期時間邏輯，為服務工作站授予更多控制權。
• HTTP 快取仍扮演重要角色，但在網路不穩定或服務中斷時並不可靠。
• 重新查看每個資源的快取策略，確定服務工作站快取策略在不與 HTTP 快取發生衝突的情況下提供值。

瞭解詳情

• 網路可靠性
• 使用 HTTP 快取防止不必要的網路要求
• HTTP 快取程式碼研究室
• 評估服務工作人員的實際效能影響
• 快取控制與到期時間