微海报离线优化小结

定义问题

由于业务发展

workbox介绍

workbox 是用来实现网页应用离线化的构建工具,通过生成的 service worker 文件,让你的离线静态资源管理策略得以在用户端实现。由于 service worker 本身是飞速发展规范,且客户端支持程度不一,通过调用 workerbox 的 API,可以最大程度的屏蔽这些兼容问题,从这个方面理解,有点像 jQuery 在 ie 时代的作用,差别是前者解决的是 service work 运行环境的兼容性问题,而 jQuery 解决的事浏览器兼容性问题。

workbox 本身集成了常用的五套缓存策略

  • Cache only;
  • Cache first, falling back to network;
  • Cache, with network update;
  • Network only;
  • Network first, falling back to cache

策略详情以及 API 可参考文档 这里不再赘述。

workbox 底层整合了sw-precache , sw-toolbox 等工具,对于熟悉这些工具的同学,理解接口和排查问题时应该会轻松些。

结合专属海报

上一篇文章可以看出,专属海报属于小型网页应用,本身没有很复杂的构建过程,所以我选择gulp作为构建工具。

专属海报实现离线化,其资源可分为三类:

1、应用自身逻辑和样式资源做预缓存(precaching):在页面加载完成后就缓存到 Cache Storage,之后除非部署新版,都将从缓存读取资源

pwa

2、cdn库文件使用运行时缓存(runtime caching),读取时采用缓存优先(cache first)策略:使用到到时候从网络加载,第二次起从缓存加载

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
{
urlPattern : 'https://vendor-Url/(.*)',
handler: 'cacheFirst',
options: {
cacheableResponse: {
statuses: [0, 200]
}
}
},
{
urlPattern : 'https://CDN-Url/(.*)',
handler: 'cacheFirst',
options: {
cacheableResponse: {
statuses: [0, 200]
}
}
}

3、请求接口的数据使用运行时缓存(runtime caching),网络优先策略(network first):优先通过网络读取,断网后从缓存读取,用于实现离线浏览(不可提交)

1
2
3
4
5
6
7
8
9
{
urlPattern : 'https://API-Url/(.*)',
handler: 'networkFirst',
options: {
cacheableResponse: {
statuses: [0, 200]
}
}
}

完整的 gulp task 可参考配置

其他场景

对于更加复杂的项目,可能 workbox 提供的缓存策略无法满足你的需求,这就需要自己定制一些路由逻辑。

对于复杂的全新项目,则可以考虑直接拿 lavas 生成脚手架,降低初始成本,不过感觉后续遇到问题,这些“省”下的时间还是要还回来的。

总结

专属海报在开发中期就已接入 workbox1.X,但考虑到项目自身还未进入稳定状态,另一方面技术规范和客户端支持程度也不确定,而且缺乏效果监控方法。综合考虑收益和风险点,一直未在生产环境启用此特性,而目前随着 iOS 的支持和技术逐渐成熟,项目接入 PWA 的时机将趋近成熟。

将新技术引入实际项目后,理论上应该解决的问题是否如预期得到解决,解决效果如何?下一篇将介绍通过在服务端定期记录 Lighthouse 跑分结果,来度量优化效果的一些思考。

参考

Google 开发者网站

饿了么的 PWA 升级实践

借助Service Worker和cacheStorage缓存及离线开发

分享到:

评论完整模式加载中...如果长时间无法加载,请针对 disq.us | disquscdn.com | disqus.com 启用代理