共计 1026 个字符，预计需要花费 3 分钟才能阅读完成。
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 的缓存里失常的被响应：