你一直在為網路可靠性而苦惱。瀏覽器的 HTTP 快取是第一道防線,但如您所知,這項功能只有在載入先前造訪過的版本網址時才有效。單靠 HTTP 快取是不夠的。
幸好,有兩項新工具可協助您扭轉局面:服務工作者和 快取儲存空間 API。由於這兩種技術經常一起使用,因此建議您同時學習這兩種技術。
Service Worker
服務工作者會內建於瀏覽器,並由您負責建立的額外 JavaScript 程式碼控制。您可以將此檔案與組成實際網頁應用程式的其他檔案一併部署。
服務工作程式具有一些特殊功能。除了其他工作外,它會耐心等待網路應用程式發出傳出要求,然後攔截並採取行動。服務工作站如何處理這項攔截要求,由您決定。
對於某些要求,最佳做法可能只是允許要求繼續傳送至網路,就像沒有服務工作者時會發生的情況一樣。
不過,對於其他要求,您可以利用比瀏覽器 HTTP 快取更具彈性的工具,並傳回可靠快速的回應,不必擔心網路問題。這需要使用另一個拼圖片:Cache Storage API。
Cache Storage API
Cache Storage API 可讓開發人員完全控管快取內容,進而開創全新可能性。Cache Storage API 不依賴 HTTP 標頭和瀏覽器內建的啟發式,而是公開程式碼驅動的快取方法。從服務工作者的 JavaScript 呼叫 Cache Storage API 時,這個 API 特別實用。
等等… 您現在要考慮另一個快取嗎?
您可能會問自己以下問題:「我還需要設定 HTTP 標頭嗎?」以及「我可以透過這個新的快取執行哪些無法透過 HTTP 快取執行的操作?」別擔心,這些都是正常反應。
即使您知道自己使用的是 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。有效使用 Cache Storage API 前,必須先將 HTTP 快取行為分類。
至於這項新 API 的功能,答案是:非常多。以下是一些常見用途,如果只使用 HTTP 快取,這些用途就很難或無法實現:
- 使用「在背景重新整理」方法處理快取內容,也就是所謂的「重新驗證時過時」。
- 為快取的素材資源數量設定上限,並實作自訂到期日政策,以便在達到上限時移除項目。
- 比較先前快取的網路回應和最新網路回應,查看是否有任何變更,並在資料實際更新時,讓使用者更新內容 (例如透過按鈕)。
詳情請參閱「Cache API:快速指南」。
API 的細節
請注意下列 API 設計事項:
- 讀取及寫入這些快取時,
Request
物件會用作專屬索引鍵。為方便起見,您可以傳入'https://example.com/index.html'
等網址字串做為鍵,而非實際的Request
物件,API 會自動為您處理。 Response
物件會用於這些快取中的值。- 在快取資料時,系統會有效地忽略指定
Response
上的Cache-Control
標頭。系統並未內建自動到期或新鮮度檢查機制,因此一旦您將項目儲存在快取中,就會持續存在,直到程式碼明確移除為止。(有程式庫可代您簡化快取維護作業。我們會在本系列的後續內容中介紹這些功能。) - 與舊版同步 API (例如
LocalStorage
) 不同,所有 Cache Storage API 作業都是非同步的。
快速岔路:承諾和 async/await
服務工作站和 Cache Storage API 會使用非同步程式設計概念。特別是,它們非常仰賴承諾來代表非同步作業的未來結果。請先熟悉承諾和相關的 async
/await
語法,再開始著手。
請勿部署該程式碼…
雖然這些服務可提供重要的基礎,且可直接使用,但服務 worker 和 Cache Storage API 都是實際上較低層級的建構元素,且有許多邊緣情況和「陷阱」。有些高階工具可協助您輕鬆處理這些 API 的困難部分,並提供建構可正式發布的服務工作程式所需的一切。下一篇指南將介紹其中一種工具:Workbox。