在 Service Worker 快取和 HTTP 快取層中使用一致或不同的到期邏輯的優缺點。
雖然服務工作處理程序和 PWA 已逐漸成為現代網頁應用程式的標準,但資源快取比以往更加複雜。本文將概略說明瀏覽器快取,包括:
- 服務工作者快取和 HTTP 快取的用途和差異。
- 比較不同服務工作者快取到期策略與一般 HTTP 快取策略的優缺點。
快取流程總覽
大致來說,瀏覽器在要求資源時,會依照下列快取順序進行:
- 服務工作者快取:服務工作者會檢查資源是否位於快取中,並根據程式設計的快取策略決定是否要傳回資源本身。請注意,系統不會自動執行這項作業。您需要在服務工作站中建立擷取事件處理常式,並攔截網路要求,以便從服務工作站的快取,而非網路提供要求。
- HTTP 快取 (也稱為瀏覽器快取):如果資源位於 HTTP 快取中且尚未過期,瀏覽器會自動使用 HTTP 快取中的資源。
- 伺服器端:如果服務工作者快取或 HTTP 快取中找不到任何內容,瀏覽器會連線至網路來要求資源。如果資源沒有在 CDN 中快取,則要求必須全部回到原始伺服器。
快取層
Service Worker 快取
服務工作站會攔截網路類型的 HTTP 要求,並使用快取策略來判斷應傳回哪些資源給瀏覽器。服務工作者快取和 HTTP 快取的一般用途相同,但服務工作者快取提供更多快取功能,例如精細控制快取內容和快取方式。
控管服務工作者快取
服務工作者會使用事件監聽器 (通常是 fetch
事件) 攔截 HTTP 要求。以下程式碼片段示範快取優先快取策略的邏輯。
強烈建議您使用 Workbox,以避免重新編寫輪子。舉例來說,您可以使用單行規則運算式程式碼註冊資源網址路徑。
import {registerRoute} from 'workbox-routing';
registerRoute(new RegExp('styles/.*\\.css'), callbackHandler);
服務工作者快取策略和用途
下表概述了常見的 Service Worker 快取策略,以及每項策略的實用時機。
策略 | 更新間隔的理由 | 用途 |
---|---|---|
僅限網路 | 內容必須隨時符合現況。 |
|
網路回復使用快取 | 最好提供最新內容。不過,如果網路發生故障或不穩定,則可放送稍舊的內容。 |
|
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 快取比 Service Worker 快取簡單許多,因為 HTTP 快取只會處理以時間為基礎的 (TTL) 資源到期時間邏輯。如要進一步瞭解 HTTP 快取策略,請參閱「應使用哪些回應標頭值?」和「摘要」。
設計快取到期邏輯
本節說明在 Service Worker 快取和 HTTP 快取層使用一致到期邏輯的優缺點,以及這些層中個別到期邏輯的優缺點。
以下 Glitch 示範 Service Worker 快取和 HTTP 快取在不同情境下的運作方式:
所有快取層的一致到期邏輯
為示範優缺點,我們將探討以下 3 種情境:長期、中期和短期。
情境 | 長期快取 | 中期快取 | 短期快取 |
---|---|---|---|
Service Worker 快取策略 | 快取,改回使用網路 | Stale-while-revalidate | 網路改用快取 |
服務工作者快取 TTL | 30 天 | 1 天 | 10 分鐘 |
HTTP 快取 max-age | 30 天 | 1 天 | 10 分鐘 |
情境:長期快取 (快取,改用網路)
- 快取資源有效 (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 快取策略 | 快取,改回使用網路 | Stale-while-revalidate | 網路改用快取 |
Service Worker 快取存留時間 | 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 快取中沒有資源的副本,因此會轉交至伺服器端。
優缺點:
- 優點:服務工作者會立即傳回快取的資源,因此使用者可立即取得回應。
- 優點:服務工作者可確保指定網址的下一個要求使用來自網路的新回應,這要歸功於「在背景」執行的重新驗證作業。
- 缺點:必須採用明確的服務工作者快取策略。
情境:短期快取 (網路改用快取)
- 當快取資源在 Service Worker 快取中有效時 (<= 1 天):服務工作站會前往資源的網路。如果 HTTP 快取中有資源,瀏覽器會傳回該資源。如果網路發生問題,服務工作站會從服務工作站快取傳回資源
- 服務工作站快取資源在快取記憶體中到期 (超過 1 天):服務工作站會前往網路擷取資源。由於其 HTTP 快取中的快取版本已過期,瀏覽器會透過網路擷取資源。
優缺點:
- 優點:當網路不穩定或中斷時,服務工作站會立即傳回快取的資源。
- 缺點:服務工作站需要額外的快取破壞機制,才能覆寫 HTTP 快取並提出「Network first」請求。
結論
由於快取情境組合的複雜性,我們無法設計一項涵蓋所有情況的規則。不過,根據前幾節的發現,設計快取策略時,請參考以下幾項建議:
- 服務工作者快取邏輯不必與 HTTP 快取到期邏輯一致。如果可以,請在 Service Worker 中使用較長的到期邏輯,授予 Service Worker 更多控制權。
- HTTP 快取仍扮演重要角色,但在網路不穩定或中斷時,就無法可靠。
- 請重新檢視各項資源的快取策略,確保服務工作單元快取策略可提供其價值,且不會與 HTTP 快取衝突。