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 将首先加载，并且可以拦截每个资源请求以加载应用程序。

即使在快速可靠的网络中，请求间的往返延迟(roundtrip delay)也会在加载应用程序时造成显着的延迟。使用 Service Worker 减少对网络的依赖，可以显着改善用户体验。

下图是向某网站发起的请求，通过 Service Worker 被响应的结果：

即使在 Chrome 开发者工具里临时把浏览器设置成 offline 模式，这些 HTTP 请求也可以从 Service Worker 的缓存里正常的被响应：