除了对缓存逻辑能提供更细粒度的管制之外,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 的基于内容的策略。