執行階段快取是指「隨行即用」逐步將回應新增至快取。 雖然執行階段快取並未協助確保「目前」的穩定性 要求程式碼，有助於提供更可靠的網址「日後」要求。
瀏覽器的 HTTP 快取是執行階段快取的一個例子只會填入資料 針對特定網址提出要求之後但服務工作處理程序可讓您 超越單獨的 HTTP 快取可提供的執行階段快取功能。
取得策略
相對於「預先快取」 (系統會一律嘗試預先快取) 提供一組預先定義的檔案，執行階段快取功能可以結合 您可以透過多種方式存取網路和快取通常每一種組合 稱為快取策略主要快取策略包括：
- 網路優先
- 快取優先
- 過時程度重新驗證
網路優先
在此方法中，您的 Service Worker 會先嘗試從 網路。如果網路要求成功，太好了！系統會將回應傳回 而回應副本則會透過「快取儲存空間」儲存 API：建立新項目，或更新舊有項目 網址。
如果網路要求完全失敗，或 所花的時間太長 傳回回應，然後傳回快取的最新回應 。
快取優先
快取優先策略與網路優先的差別就在於。在本 方法，當 Service Worker 攔截要求時，會先使用快取 Storage API，確認是否有可用的快取回應。如果有 即可將回應傳回網頁應用程式
但如果快取失敗，Service Worker 就會前往該網路 並嘗試擷取回應中的假設該網路要求 系統會將檔案傳回網頁應用程式，並將副本儲存在快取中。這個 快取副本將會在下次要求 產生相同網址
過時程度重新驗證
重新驗證過時的情況就屬於混合型環境。使用時，您的服務 工作站會立即檢查快取的回應，如果找到，則 並傳回至網頁應用程式
在此期間，無論快取是否相符，您的服務 工作站也會發出網路要求來取回「最新」回應。這個 回應即可更新先前快取的任何回應。如果初始快取 有一次網路回應失敗，網路回應也會傳回您的網頁 應用程式。
為什麼要使用 Workbox？
這些快取策略足以應付您平時必須執行的食譜 重新編寫您的 Service Worker。有鑑於此 透過 Workbox，您可以將工作方式打包在 策略庫 一切準備就緒
Workbox 也支援版本管理 到期 快取項目，或在擷取要求記錄時 更新 先前快取的項目
你應該使用哪些策略來快取哪些資產？
執行階段快取可視為預先快取的補充資料。如果您 系統已預先快取資產，就大功告成了，無需再採取任何動作 以便在執行階段快取至於相對複雜的網頁應用程式 但系統就不會預先快取「所有內容」
大型媒體檔案、由第三方主機 (例如 CDN) 提供的素材資源 這裡只是舉幾個例子 以有效的方式預先快取使用開發人員工具中的「網路」面板識別要求 並想想每個項目的 時效性和可靠性是合適的選擇
使用過時程度重新驗證，優先考慮可靠性，而非更新間隔
因為過時的重新驗證策略幾乎會傳回快取回應 快取填入第一個要求後立即停止執行 原本就在採用這項策略時，成效更穩定。這部分隨附 以便權衡擷取過時的回應資料 我會從網路擷取哪些資訊採用這項策略的成效最佳 針對使用者個人資料或初始 API 回應等資產 填入檢視畫面，在您知道「立即」顯示資訊的情況下是關鍵， 還是較舊的值
使用網路優先，優先考量更新速度而非可靠性
某種程度來說，採用網路優先策略是在戰鬥中贏得勝利 這對網路來說是重要的優先順序，但也充滿不確定性 可靠性通常相當高對於特定類型的資產 則傾向取得過時資訊。您可能會希望在 對經常更新的文章文字提出 API 要求，例如 執行個體。
在 Service Worker 中使用網路優先策略 與聯播網直接往來，好處則是 返回特定內容。您不會 速度可靠，但至少您在離線時仍能保持穩定。
針對版本化網址使用快取優先
在快取優先策略中，項目一旦快取，永遠不會更新。為此
建議您只搭配不可能使用的素材資源
變更。特別是用於含有版本管理的網址
資訊，就代表應同時向
Cache-Control: max-age=31536000 回應標頭。