執行階段快取是指「隨時隨地」逐步新增回應至快取。雖然執行階段快取無法提高「目前」要求的可靠性，但可以協助針對相同網址提出「未來」要求。
瀏覽器的 HTTP 快取是執行階段快取的範例，只有在要求指定網址之後才會填入。但服務工作站可讓您實作執行階段快取，超出 HTTP 快取功能的唯一性。
擬定策略
與「預先快取」不同 (後者一律會嘗試從快取提供一組預先定義的檔案)，執行階段快取能以多種方式結合網路和快取存取權。每個組合通常稱為快取策略。主要快取策略包括：
- 網路優先
- 快取優先
- 重新驗證時過時
網路優先
在這個方法中，服務工作站會先嘗試從網路擷取回應。如果網路請求成功，那就太好了！回應會傳回網頁應用程式，且回應副本會使用 Cache Storage API 儲存，即建立新項目或更新相同網址的項目。
如果網路要求完全失敗，或是時間過長才傳回回應，系統會改為傳回快取中最新的回應。
快取優先
快取優先的策略實際上與網路優先的策略不同。以這種方式來說，服務工作站攔截要求時，會先使用 Cache Storage API 來查看是否有可用的快取回應。如果找到，系統會將該回應傳回至網頁應用程式。
但如果快取失敗，服務工作站會進入網路，並嘗試從該網路擷取回應。假設網路要求成功，系統會將網路要求傳回至網頁應用程式，並將副本儲存在快取中。下次對相同網址提出要求時，系統會使用這個快取副本略過網路。
重新驗證時過時
過時/重新驗證是混合型。使用此方法時，您的服務工作站將立即檢查快取回應，如果找到，請將其傳回您的網頁應用程式。
同時，無論快取是否有相符結果，您的服務工作站也會透過網路要求來傳回「fresh」回應。這個回應可用來更新任何先前快取的回應。如果初始快取檢查失敗，系統也會將網路回應的副本傳回您的網頁應用程式。
為什麼要使用 Workbox？
這些快取策略等同於您通常需要在自己的服務工作站中重新編寫的方案。Workbox 不考慮採用此方法，而是將這些套件封裝成其策略程式庫，可讓您提供給服務工作站。
此外，Workbox 也提供版本管理功能，可以自動過期快取項目，或在先前快取項目發生更新時通知網頁應用程式。
哪些資產需要快取？哪些策略？
執行階段快取可做為預先快取的輔助。如果所有資產皆已預先快取，就完成了，則無需在執行階段快取任何項目。但對於相對複雜的網頁應用程式，您可能不需要預先下載「所有內容」。
更大的媒體檔案、由第三方主機 (例如 CDN) 提供的資產，或 API 回應，僅列舉無法有效預先快取的資產類型。使用開發人員工具中的「網路」面板識別屬於這個類別的要求，然後針對每個要求，思考在頻率與可靠性之間的取捨。
使用 stale-while-revalidate
過時時間重新驗證策略幾乎會立即傳回快取回應 (透過第一個要求填入快取後)，因此當您採用這種策略時，就能看到穩定快速的效能。相對地，如果傳回的回應資料可能過時，而不是從網路擷取的資料會過時，那就不必再取得這類回應。此策略最適合用於資產，例如使用者個人資料圖片或用於填入檢視區塊的初始 API 回應，但如果您知道內容「立即」是關鍵，即使該值舊值也是如此。
使用網路優先功能優先考慮更新間隔，而非可靠性
某種程度上，採用網路優先的策略可允許您在對網路的戰鬥中取得勝利。除了優先事項以外，但這也導致對可靠性的不確定性造成了不確定性。對於特定類型的資產，看到最新回應較適合取得過時的資訊。舉例來說，對於經常更新的報導文字提出 API 要求時，您可能會偏好使用新鮮度。
在 Service Worker 內使用網路優先策略，而不是直接對網路進行連線，因此能夠順利改回使用「某個問題」，即使該回應可能已過時。雖然速度較快，但至少在離線時可確保穩定運作。
針對版本化網址使用快取優先功能
在快取優先策略中，快取項目後永遠不會更新。基於這個理由，請務必只將其用於您知道不太可能變更的素材資源。尤其適合含有版本資訊的網址，也就是同樣應透過 Cache-Control: max-age=31536000 回應標頭提供的相同類型網址。