（公开代表某人问/答。）
我正在使用Workbox生成服务工作者，该工作者为我的渐进式Web应用程序预缓存资源。
我不愿意预缓存约20mb的缩小JavaScript是错误的吗？显然，它很大。 20mb似乎太多了。我的计划是只预缓存必要的内容，其余部分使用运行时缓存。
换句话说，用于确定哪些应该和不应该包含在预缓存有效载荷中的一般启发式方法是什么？
答案 0 :(得分：8)
这里有很多细微差别，正确的答案归结为了解用户和了解资源的组合。
主要考虑因素之一是强制大约20mb的数据下载是否符合您的目标用户群。
如果您正在为公司客户开发内部PWA，那么您可以确定大多数用户将处于快速连接状态，而不必为数据计划支付兆字节的费用。
如果您要开发的市场中包括连接速度较慢，按计量连接的人员，那么避免自动预缓存大型有效负载是个好主意。您可以减小预缓存的有效负载大小，或者延迟服务工作者的注册，直到他们与您的PWA进行了一点接触–那时，如果他们正在使用您的站点，则他们更有可能从事物中获取价值。被缓存，就不会像“路过的数据转储”。
在最初的问题中，据说〜20mb是JavaScript资源，我的假设是它们都是为网络应用中的各种视图延迟加载的资产。
除了考虑预缓存的初始成本外，您还应关注随着时间的推移对站点进行更改时过期和重新获取先前已预缓存的条目的持续成本。
如果您预先缓存了20个单独的捆绑包，每个捆绑包的大小约为1mb，那么在其中一个捆绑包中对单个文件进行更改将导致大约1mb的数据作为后续更新的一部分进行传输。如果您有2个单独的捆绑包，每个捆绑包的大小约为10mb，那么更改同一文件将导致约10mb的数据传输。随着时间的推移，使预缓存资产保持最新状态的成本很容易超过预缓存的初始成本，因此在捆绑时请记住这一点。
这是从上一点开始的-尝试避免预先缓存仅由一小部分用户请求的惰性加载资产。即使资产本身很小，每次您对组成捆绑包的任何文件进行更改时，这些用户都要付费以保持资产更新。您可以轻松地介绍一种情况，随着时间的流逝，用户将下载并重新下载JS，这些JS最终将永远不会被执行。
（假设您正在考虑是否预缓存图像。）
除非在许多页面上将其用作用户界面的一部分，否则图像不是预缓存的理想选择。它们显然很大，并且如果由于您处于离线状态并且不在缓存中而导致加载失败，那么希望您在HTML标记中有替代文本可以显示在它们的位置。
使用运行时缓存策略以及缓存过期策略通常是对图像的最佳建议。