Service Worker 快取 API 的一個主要優點是它為您提供了比內建瀏覽器快取更詳細的控制。 例如，Service Worker 可以在使用者首次執行您的 Web 應用程式時快取多個請求，包括他們尚未訪問的資產。 這將加快後續請求。 還可以實現自己的快取控制邏輯，確保被認為重要的資產保留在快取中，同時刪除較少使用的資料。

如果使用快取頭來快取頁面上的元素，使用者觸發的重新整理將使瀏覽器跳過 HTTP 快取。但是，Service Worker fetch 事件將始終攔截請求，這意味著如果開發人員願意，可以隨時從快取中提供服務。

Service Worker 增強了傳統的 Web 應用部署模型，並使應用程式能夠提供與在終端使用者的作業系統和硬體上執行原生應用同等的可靠性和效能的使用者體驗。

將 Service Worker 新增到 Angular 應用程式，是將應用程式轉變為漸進式 Web 應用程式（也稱為 PWA）的步驟之一。

一言以蔽之，我們可以將 Service Worker 看成是在 Web 瀏覽器中執行並管理應用程式快取的指令碼。

Service Worker 充當網路代理。 它們攔截應用程式發出的所有傳出 HTTP 請求，並能夠透過程式設計的方式，指定 Service Worker 如何響應這些請求。

例如，Service Worker 可以查詢本地快取並提供快取響應（如果可用）。這種攔截和代理行為，不僅限於透過程式設計 API 發出的請求，例如 fetch；它還包括在 HTML 中引用的資源，甚至是對 index.html 的初始請求。 因此，基於 Service Worker 的快取是完全可程式設計的，並且不依賴於伺服器指定的快取標頭——後者是 HTTP 層的快取，同 Service Worker 快取位於兩個不同的層。

與構成應用程式的其他指令碼（例如 Angular 應用程式包）不同，Service Worker 即使在使用者關閉 Chrome 瀏覽器的 tab 之後，仍然被保留。

下次該瀏覽器載入應用程式時，Service Worker 將首先載入，並且可以攔截每個資源請求以載入應用程式。

![](https://img-blog.csdnimg.cn/img_convert/a7ef57f16cc0b8585b717458a93de930.png)

即使在快速可靠的網路中，請求間的往返延遲(roundtrip delay)也會在載入應用程式時造成顯著的延遲。使用 Service Worker 減少對網路的依賴，可以顯著改善使用者體驗。

下圖是向某網站發起的請求，透過 Service Worker 被響應的結果：

![](https://img-blog.csdnimg.cn/img_convert/7e9b2b4ba9f0ac8d6240433b353e760a.png)

即使在 Chrome 開發者工具裡臨時把瀏覽器設定成 offline 模式，這些 HTTP 請求也可以從 Service Worker 的快取里正常的被響應：
![](https://img-blog.csdnimg.cn/img_convert/536f3061cdaafc04a57f28010164b1a8.png)

在 Chrome 開發者工具裡透過 network 選項模擬網站的離線訪問模式

相關文章