迹忆客 专注技术分享

首先，了解一些背景

Service Worker 和 Cache Storage API 提供了一些非常低级的原语，开发人员希望在这些原语之上构建。 “The Offline Cookbook”中概述了一些行之有效的常见方式。 想要为这些策略提供更高级别包的开发人员通常求助于 Workbox 库。 一般来说，Workbox 将缓存分为两种方法。

有预缓存，其中构建工具（如 workbox-cli 或 workbox-webpack-plugin）生成 URL 和修订的清单，然后将其馈送到 workbox-precaching 运行时模块。 基于预缓存清单，workbox-precaching 使你的缓存保持最新，并使用缓存优先策略设置路由以提供预缓存的 URL。

还有运行时缓存，你可以在其中混合使用工作箱路由和工作箱策略（以及任何插件）。

如果你愿意，Workbox 可以让你全力以赴进行运行时缓存的预缓存，但你也可以在同一个服务进程中使用这两种类型的缓存。 （如果你这样做，你注册路由的顺序是导入；你应该在任何额外的 registerRoute() 语句之前包含 precacheAndRoute() 以确保你的预缓存清单中的任何内容最终通过预缓存策略提供服务！）

为了帮助开发人员决定哪些 URL 应该被预缓存，哪些应该被运行时缓存，下面是每种方法的优缺点的粗略概述。 我们会将这些信息正式化，作为即将到来的、早该对 Workbox 文档进行的修改的一部分，但我最近写这篇文章是出于不同的目的，所以我想我应该公开它。

预缓存优点

• 缓存优先对于不包含散列的 URL 是“安全的”，因为修订信息是在构建时生成的，并在预缓存清单中带外维护。
• 允许你以原子方式从一个版本的缓存子资源“升级”到另一个版本。 （例如，如果你的模板和 JavaScript 呈现逻辑都需要相互一致地缓存，则很有用。）
• 你可以轻松地缓存后续页面所需的资源，而不是等待 Service Worker 控制并拦截运行时缓存的请求。 （你可以通过将项目显式添加到运行时缓存来稍微解决这个问题。）

  预缓存缺点

• 需要构建步骤。
• 在 Service Worker 安装期间无条件缓存所有内容。 如果您在预缓存清单中包含不常使用的子资源的 URL，或者像图像这样的大型资源，那可能会造成浪费，因为您正在缓存永远不会被读取的内容。
• 预缓存经常更新的资源会导致大量的“缓存流失”。 这对于常用的子资源来说很好，但最坏的情况是您预缓存了一个不常使用但经常更新的子资源，从而增加了上一点中描述的浪费字节。

运行时缓存优点

• 适用于无法在构建时确定哈希值的 URL。 （这是大多数动态或服务器呈现内容的问题。）
• 灵活地使用网络优先或缓存优先策略，让你可以控制新鲜度与速度的权衡。
• 基于路由规则和缓存过期插件，允许不同子资源的缓存生命周期相互独立存在。

运行时缓存缺点

• 如果页面依赖于尚未缓存的资源，用户最终可能会获得中断的离线体验。
• 如果给定的 URL 不包含哈希或版本控制信息，则使用缓存优先策略通常是不安全的。 你可以做的最好的事情是stale-while-revalidate，以确保缓存的资源最终得到更新。
• 缓存资源没有原子更新。 一个 JavaScript 子资源最近可能已通过一种在重新验证时失效的策略进行了更新，而你的模板却没有，这可能导致互操作性不匹配或不正确的假设。
• 假设你的 URL 确实包含散列等版本控制信息，则没有内置机制可以在缓存中有新资源时自动使给定资源的先前修订过期。 （不过，我一直在通过 Workbox 插件尝试解决方案。）

我通常的做法是尽可能多地进行预缓存，因为我的大多数网络应用程序已经有一个构建过程，它们的大小通常是有限的（比如，所有应用程序内容都在 1 兆字节以下），而且我不这样做 经常搅动我的缓存资源。 每当我混合使用运行时缓存时，通常是针对无法在构建时进行版本控制的内容（例如实时 API 结果）或图像，我不想强迫每个人在 Service Worker 安装期间下载这些内容。