service-worker - 推荐的预缓存负载大小？

Question

(代表某人公开询问/回答。)

我正在使用 Workbox 生成一个 Service Worker，为我的渐进式 Web 应用程序预缓存资源。

不愿意预缓存 ~20mb 的缩小 JavaScript 是我错了吗？很明显，它很大。 20mb 似乎太多了。我的计划是只预缓存必要的东西，其余的使用运行时缓存。

换句话说，确定什么应该和不应该包含在预缓存负载中的一些一般启发式方法是什么？

Answer 1

这里有很多细微差别，正确的答案归结为了解您的用户和了解您的资源的组合。

用户注意事项

主要考虑因素之一是强制下载约 20 mb 的数据是否尊重您的目标用户群。

如果您正在为企业客户开发内部 PWA，那么您可能相当确定大多数用户将使用快速连接，而不是为他们的数据计划支付兆字节的费用。

如果您正在开发的市场包括使用速度较慢的计量连接的人，那么避免自动预缓存大型有效负载是一个好主意。你可以减少你的预缓存负载大小，或者延迟 service worker 的注册，直到他们稍微接触你的 PWA 之后——在这一点上，如果他们正在使用你的网站，他们更有可能从事物中获得值(value)被缓存，它不会感觉像“路过数据转储”。

了解您的资源

在最初的问题中，大约 20mb 被认为是 JavaScript 资源，我的假设是它们都是为您的 Web 应用程序中的各种 View 延迟加载的 Assets 。

更喜欢许多较小的单个 Assets ，而不是较少的捆绑较大的 Assets

除了考虑预缓存的初始成本之外，您还应该关注随着时间的推移对站点进行更改时过期和重新获取先前预缓存的条目的持续成本。

如果您预缓存了 20 个单独的包，并且每个包的大小约为 1mb，那么对其中一个包中的单个文件进行更改将导致传输约 1mb 的数据作为后续更新的一部分。如果您有 2 个单独的包，每个包的大小约为 10mb，那么更改同一个文件将导致传输约 10mb 的数据。随着时间的推移，保持预缓存 Assets 最新的成本很容易超过预缓存的初始成本，因此在捆绑时尽量记住这一点。

仅为可能使用的 View 预缓存 Assets

这是从上一点开始的——尽量避免预缓存延迟加载的 Assets ，这些 Assets 只会被低比例的用户请求。即使 Assets 本身很小，但每次更改构成这些捆绑包的任何文件时，这些用户仍需支付保持更新的成本。您可以轻松地引入一种情况，随着时间的推移，用户下载并重新下载永远不会被执行的 JS。

不要预缓存图像(通常)

(这假设您正在考虑是否预缓存图像。)

图像，除非它们在许多页面上用作用户界面的一部分，否则不适合进行预缓存。它们显然往往很大，如果它们由于您离线而无法加载并且它们不在缓存中，那么希望您的 HTML 标记中有替代文本可以显示在它们的位置。

使用运行时缓存策略以及缓存过期策略通常是图像的最佳建议。