Hen*_*nry 4 progressive-web-apps workbox
我添加了一些workbox.routing.registerRoute使用staleWhileRevalidate到我的应用程序,到目前为止它已通过PWA下的大多数灯塔测试.我目前没有使用Precaching.我的问题是,它是强制性的吗？没有预先准备,我错过了什么？workbox.routing.registerRoute已经缓存了我需要的一切.谢谢!
Jef*_*ick 15
没有必要.:-)
对所有资产以及HTML使用stale-while-revalidate绝对是一种合法的方法.这意味着您不必在构建过程中执行任何特殊操作,例如,在某些情况下这可能很好.
每当您使用从缓存中读取的策略时,无论是通过预缓存还是通过重新验证,都会有某种重新验证步骤,以确保您不会无限期地提供过期响应.
如果您使用Workbox的预缓存,那么重新验证是有效的,因为浏览器只需要为您生成的service-worker.js文件发出单个请求,并且该响应可以作为事先是否实际更改的事实的真实来源.假设你的预缓存资产不改变该频繁,大部分的时间你service-worker.js将等同于它被检索的最后时间,也不会有在更新中使用任何进一步的带宽和CPU周期.
如果您对所有内容使用运行时缓存和重新生效的策略,那么每个响应都会发生"while-revalidate"步骤.您几乎会立即将"陈旧"响应返回到页面,因此您的整体性能应该仍然很好,但是您需要"服务工作者"在后台发出额外请求以重新获取每个URL,并且更新缓存.此方法中使用的带宽和CPU周期有所增加.
除了使用额外的资源之外,您可能更喜欢预先缓存到重新验证的另一个原因是您可以提前填充完整缓存,而无需等待第一次访问它们.如果某些资产仅用于您的Web应用程序的子部分,并且您希望提前缓存这些资产,那么如果您只进行运行时缓存,那将会更加棘手.
并通过预先缓存提供的一个好处是,它会更新缓存集体.这有助于避免例如一个JavaScript文件由于在前一页上被请求而更新的情况,但是当您导航到下一页时,较新的JavaScript与过时的HTML提供的DOM不兼容.预先处理一切可以减少这些版本错配发生的可能性.(特别是如果你没有启用skipWaiting.)
| 归档时间： |
|
| 查看次数： |
790 次 |
| 最近记录： |