除了对缓存逻辑能提供更细粒度的管制之外，Service Worker 缓存还提供：
- 为您的源提供更多内存和存储空间：浏览器按源调配 HTTP 缓存资源。换句话说，如果您有多个子域，它们都共享雷同的 HTTP 缓存。无奈保障您的源 / 域的内容会长工夫保留在 HTTP 缓存中。例如，用户能够通过从浏览器的设置 UI 中手动清理或触发页面上的硬从新加载来革除缓存。应用服务工作者缓存，您的缓存内容放弃缓存状态的可能性要高得多。
- 在不稳固的网络或离线体验畛域具备更高的灵活性：应用 HTTP 缓存，开发人员只有一个二元抉择：要么缓存资源，要么不缓存。应用 Service Worker 缓存，能够更轻松地缓解网络不稳固的时候利用可能呈现的问题（应用
stale-while-revalidate策略），或者提供残缺的离线体验（应用cache only策略），甚至介于两者之间，例如自定义 UI 页面的某些局部来自 service worker 缓存，并且在适当的状况下排除了某些局部（应用Set catch handler策略）。
当然，HTTP 缓存作为一项成熟的技术，能够作为 Service Worker 缓存无益的补充。
浏览器第一次加载网页和相干资源时，会将这些资源存储在其 HTTP 缓存中。HTTP 缓存通常由浏览器主动启用，除非最终用户明确禁用它。
应用 HTTP 缓存意味着依附服务器来确定何时缓存资源以及缓存多长时间。
当服务器响应浏览器对资源的申请时，服务器应用 HTTP 响应标头通知浏览器应该缓存资源多长时间。
看一个例子：
- ETAG: 当浏览器发现一个过期的缓存响应时，它能够向服务器发送一个小令牌（通常是文件内容的哈希）以查看文件是否已更改。如果服务器返回雷同的令牌，则文件是雷同的，无需从新下载。这个令牌呈现在浏览器发送给服务器的 HTTP 申请的头部：
If-None-Match: "62e701da-63ba-gzip"
- Last-Modified：此标头与 ETag 的用处雷同，但应用基于工夫的策略来确定资源是否已更改，而不是 ETag 的基于内容的策略。