推荐的预有效载荷大小？

Question

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

我正在使用Workbox生成一个服务工作者,为我的渐进式Web应用程序预留资源.

我不愿意预先安排〜20mb的缩小JavaScript吗？显然,这是巨大的.20mb似乎太过分了.我的计划是只预先处理基本内容,然后使用运行时缓存.

换句话说,什么是一些通用的启发式方法来确定应该和不应该包含在预先缓存有效负载中的内容？

Answer 1

这里有很多细微差别,正确的答案归结为了解用户和理解资源.

用户注意事项

其中一个主要考虑因素是强制下载大约20mb的数据是否尊重您的目标用户群.

如果您正在为公司客户开发内部PWA,那么您可能相当确定大多数用户将进行快速连接,而不是按兆字节为他们的数据计划付费.

如果您正在开发一个包含较慢的计量连接的市场,那么避免自动预先处理大型有效负载是一个好主意.你可以减少你的预先缓存有效负载大小,或者延迟服务工作者注册,直到他们与你的PWA有点接触为止,如果他们使用你的网站,他们更有可能从事物中获取价值被缓存,它不会像一个"偷渡式数据转储".

了解您的资源

在最初的问题中,大约20mb被认为是JavaScript资源,我的假设是它们都是懒惰加载到您的Web应用程序中的各种视图的资产.

优先选择较小的个人资产,而不是捆绑较大的资产

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

如果预先有20个单独的捆绑包,并且每个捆绑包都是〜1mb,那么对其中一个捆绑包中的单个文件进行更改将导致〜1mb的数据作为后续更新的一部分进行传输.如果你有2个单独的包,每个都是〜10mb,那么更改同一个文件将导致~10mb的数据被传输.随着时间的推移,使预先缓存的资产保持最新的成本很容易超过预先缓存的初始成本,因此在捆绑时要记住这一点.

仅适用于可能使用的视图的预缓存资产

这是从前一点开始的 - 尝试避免预先缓存的延迟加载资产,这些资产只会被低百分比的用户请求.即使资产本身很小,但每次对组成这些捆绑包的任何文件进行更改时,这些用户需要付费才能保持最新状态.您可以轻松地介绍一种情况,即随着时间的推移,用户下载并重新下载永远不会被执行的JS.

不要预先缓存图像(通常)

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

图像,除非它们在许多页面上用作用户界面的一部分,否则不适合预先缓存.它们显然往往很大,如果由于你处于脱机状态而无法加载而且它们不在缓存中,那么希望你的HTML标记中有替代文本可以显示在它们的位置.

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