您可能受困於網路穩定性。瀏覽器的 HTTP 快取是您的第一道防線，但如您所知，只有在載入您先前瀏覽過的版本化網址時，才算有效。HTTP 快取本身是不夠的
幸運的是，Service Worker 和 Cache Storage API 都提供了兩種較新的工具，協助您做出明智的調整。由於兩者非常常用，建議您同時瞭解兩者。
Service Worker
Service Worker 已內建在瀏覽器中，並由你負責建立的額外 JavaScript 程式碼控制。接著，您要部署這段程式碼，與其他構成實際網頁應用程式的其他檔案一起部署。
Service Worker 具備一些特殊功能。除了工作之外，它會耐心等待網頁應用程式發出傳出要求，然後攔截要求來採取行動。至於處理這個攔截要求，服務工作站會採取哪些動作，完全由您決定。
對某些要求而言，最好的做法是允許要求繼續留在網路中，就像完全沒有 Service Worker 時會發生的情況一樣。
不過，針對其他要求，您可以善用比瀏覽器的 HTTP 快取更有彈性的功能，並且能傳回穩定的快速回應，而不必擔心網路的問題。亦即要使用 Cache Storage API 的其他部分。
Cache Storage API
Cache Storage API 可讓開發人員完全控管快取內容，進而開創出全新的可能性。Cache Storage API 提供以程式碼為準的快取方法，而不是依賴 HTTP 標頭和瀏覽器內建的heuristics。從服務工作站的 JavaScript 呼叫時，Cache Storage API 特別實用。
等等...現在有其他快取需要考慮嗎？
您可能會問自己下列問題：別擔心，這些是自然的回應。
即使您知道正在使用 Cache Storage API，我們仍建議您在網路伺服器上設定 Cache-Control 標頭。針對未版本網址設定 Cache-Control: no-cache，和/或為包含版本化資訊 (例如雜湊) 的網址設定 Cache-Control: max-age=31536000，通常可以移除。
填入 Cache Storage API 快取時，瀏覽器會預設檢查 HTTP 快取中的現有項目，並在找到這些項目的情況下使用。如果您將版本化網址新增至 Cache Storage API 快取，瀏覽器會避免發出額外的網路要求。相反地，若使用設定錯誤的 Cache-Control 標頭 (例如為未版本化的網址指定長期快取生命週期)，可以將過時內容新增至 Cache Storage API，讓事情惡化。您必須先取得已排序的 HTTP 快取行為，才能有效使用 Cache Storage API。
就現在這個新的 API 可以做到的，答案非常多。僅使用 HTTP 快取很難或不可能的常見用途包括：
- 使用「在背景重新整理」方法處理快取內容，稱為「過時時重新驗證」。
- 對快取資產數量上限設下上限，並實作自訂到期日政策，在達到上限後移除項目。
- 比較先前快取和最新的網路回應，確認是否有任何異動，並在資料實際更新時讓使用者更新內容 (例如透過按鈕)。
詳情請參閱 Cache API：快速指南。
API 基本知識與螺栓
關於 API 設計，請注意下列事項：
- 讀取及寫入這些快取時，系統會使用
Request物件做為不重複鍵。為方便起見，您可以傳入網址字串 (例如'https://example.com/index.html') 做為鍵 (而非實際的Request物件)，API 會自動為您處理。 Response物件會當做這些快取中的值使用。- 快取資料時，系統會有效忽略特定
Response上的Cache-Control標頭。系統不會自動、內建到期時間或更新間隔檢查，而您將項目儲存在快取中後，該項目將持續存在，直到程式碼明確移除為止。(有些程式庫可為您簡化快取維護作業。)稍後將在本系列文章中說明。) - 與較舊版本的同步 API (例如
LocalStorage) 不同，所有 Cache Storage API 作業都是非同步的。
快速指導：承諾和非同步/等待
Service Worker 和 Cache Storage API 採用非同步程式設計概念。特別是，它們極度仰賴承諾來代表非同步作業的未來結果。開始探索前，請先熟悉承諾以及相關的 async/await 語法。
請先不要部署該程式碼...
雖然服務工作站和 Cache Storage API 都是提供重要基礎且直接採用，但實際上是低階的建構模塊，具有許多極端案例和「Gotchas」。有些更高階的工具可協助簡化這些 API 的複雜性，並提供所有必要功能，讓您建構可立即用於實際工作環境的 Service Worker。下一份指南會介紹其中一個工具：Workbox。