这里有很多细微差别，正确的答案取决于了解用户和了解资源的结合。
用户考虑因素
主要考虑因素之一是强制下载约 20mb 的数据是否尊重您的目标用户群。
如果您正在为企业客户开发内部 PWA，那么您可能相当确定大多数用户将使用快速连接，而不是按兆字节为其数据计划付费。
如果您正在为一个包含速度较慢、按流量计费的连接的市场进行开发，那么避免自动预缓存大型负载是一个好主意。您可以减少预缓存有效负载大小，或者延迟服务工作人员注册，直到他们与您的 PWA 进行了一些接触之后，此时，如果他们正在使用您的网站，他们更有可能从事物中获取价值被缓存，并且不会感觉像“路过的数据转储”。
了解您的资源
在最初的问题中，大约 20mb 被认为是 JavaScript 资源，我的假设是它们都是为 Web 应用程序中的各种视图延迟加载的资源。
更喜欢许多较小的单独资产，而不是较少的捆绑较大资产
除了考虑预缓存的初始成本之外，您还应该关注随着时间的推移对站点进行更改而导致先前预缓存的条目过期和重新获取的持续成本。
如果您预缓存了 20 个单独的包，并且每个包的大小约为 1mb，那么对其中一个包中的单个文件进行更改将导致在后续更新中传输约 1mb 的数据。如果您有 2 个单独的捆绑包，每个捆绑包的大小约为 10mb，则更改同一文件将导致传输约 10mb 的数据。随着时间的推移，保持预缓存资源最新的成本很容易超过预缓存的初始成本，因此在捆绑时请记住这一点。
仅预缓存可能使用的视图的资源
这是从上一点得出的——尽量避免预缓存只有一小部分用户会请求的延迟加载资源。即使资产本身很小，每次您对组成这些捆绑包的任何文件进行更改时，这些用户也要支付一定的费用来使它们保持最新状态。您可以轻松地引入这样一种情况：随着时间的推移，用户下载并重新下载永远不会被执行的 JS。
不要预缓存图像（通常）
（这假设您正在考虑是否预缓存图像。）
图像，除非在许多页面上用作用户界面的一部分，否则不适合预缓存。它们显然往往很大，如果由于您处于离线状态并且它们不在缓存中而无法加载，那么希望您的 HTML 标记中有替代文本可以显示在它们的位置。
使用运行时缓存策略以及缓存过期策略通常是图像的最佳建议。
