推荐的预缓存负载大小? [英] Recommended precache payload size?

问题描述

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

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

I'm using Workbox to generate a service worker that precaches resources for my progressive web app.

我不愿意预缓存约 20mb 的缩小的 JavaScript 是不是我错了?很明显，它很大.20mb 似乎太多了.我的计划是只预缓存必要的内容，其余使用运行时缓存.

Am I wrong to be reluctant to precache ~20mb of minified JavaScript? It's huge, obviously. 20mb seems way too much. My plan was to just precache the essential stuff, and use runtime caching for the rest.

换句话说，有哪些通用的启发式方法可以确定哪些内容应该和不应该包含在预缓存负载中?

In other words, what are some general heuristics for determining what should and shouldn't be included in the precache payload?

推荐答案

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

There's a lot of nuance here, and the right answer comes down to a mix of understanding your users and understanding your resources.

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

One of the main considerations is whether forcing a ~20mb download of data is respectful of your target user base.

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

If you're developing an in-house PWA for a corporate client, then you might be fairly sure that the majority of users will be on a fast connection, and not paying by the megabyte for their data plan.

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

If you're developing for a market that includes folks who are on slower, metered connections, avoiding automatic precaching of large payloads is a good idea. You could either decrease your precache payload size, or alternatively, delay service worker registration until after they've engaged with your PWA a bit—at that point, if they're using your site, they're more likely to derive value from things being cached and it won't feel like a "drive-by data dump".

在最初的问题中，大约 20mb 被认为是 JavaScript 资源，我的假设是它们都是为您的网络应用程序中的各种视图延迟加载的资产.

In the original question, the ~20mb were said to be JavaScript resources, and my assumption is that they are all assets that are lazy-loaded for various views in your web app.

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

Beyond thinking about the initial cost of precaching, you should be concerned with the ongoing cost of expiring and refetching entries that were previously precached as you make changes to your site over time.

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

If you have 20 individual bundles precached, and each of those are ~1mb, then making a change to a single file in one of the bundles will cause ~1mb of data to be transferred as part of the follow-on update. If you have 2 individual bundles and each are ~10mb, then changing that same file will cause ~10mb of data to be transferred. The cost of keeping your precached assets up to date can, over time, easily outweigh the initial cost of precaching, so try to keep that in mind when bundling.

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

This follows from the previous point—try to avoid precaching lazy-loaded assets that are only going to be requested by a low percentage of your users. Even if the assets themselves are small, there's a cost of keeping them up to date that those users pay each time you make a change to any of the files that make up those bundles. You could easily introduce a situation where, over time, a user downloads and re-downloads JS that will never end up being executed.

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

(This assumes that you're considering whether to precache images.)

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

Images, unless they're used as part of your user interface on many pages, are not great candidates for precaching. They obviously tend to be large, and if they fail to load because you're offline and they're not in the cache, then hopefully you have alternative text in your HTML markup to display in their place.

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

Using a runtime caching strategy, along with a cache expiration policy, is usually the best advice for images.

这篇关于推荐的预缓存负载大小?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！