service work 关于更新用户本地缓存的方案

简介: service work + cache 可以用来对网站的一些资源进行本地缓存,甚至可以实现离线访问的功能(如果你的网站是纯静态的)。

service work + cache 可以用来对网站的一些资源进行本地缓存,甚至可以实现离线访问的功能(如果你的网站是纯静态的)。

handsome主题最新版本也使用了此项技术实现的本地缓存,也许你在第一次进入博客的后续的访问会觉得速度很快,很大的原因可能是在此。

简单实现

在介绍sw更新缓存方案之前,先来简单介绍sw的工作原理。

我们通过register api 注册一个sw.js,此时该js文件的代码会运行在一个独立的js环境,不需要访问dom,但是具有更高权限。

window.addEventListener('load', function() {
    navigator.serviceWorker.register('/sw.js').then(function(registration) {
      // Registration was successful
      console.log('ServiceWorker registration successful with scope: ', registration.scope);
    }, function(err) {
      // registration failed :(
      console.log('ServiceWorker registration failed: ', err);
    });
  });

我们一般会在activated 状态下判断是否需要删除旧的缓存(根据缓存的key)。

sw 一个很强大的功能是fetch 事件,能够捕获当前域下的所有请求,我们可以通过这个事件捕获请求,决定直接返回缓存还是进行网络请求,甚至修改请求头和响应体等等。对于网络请求获取的结果可以判断是否需要进行缓存。

更新缓存

本文主要想讨论一下当被缓存的内容需要更新的时候,如何更新用户浏览器中的本地缓存。

sw的生命周期是:install -> waiting -> activate -> fetch

即开始注册、等待激活,激活完毕,监听页面的请求。

sw.js 是通过该函数navigator.serviceWorker.register(url:string)来注册一个service worker。

当执行这个函数的时候,浏览器如果发现这个url的文件内容有修改(和之前已经注册的sw比较),则会重新安装新版本(install->Wating)

浏览器会在空闲的时候(比如页面没有请求发生)才会替换上一个sw,而不是立即执行,这就是为什么会有wating阶段的原因。

但是我们可以在install阶段中使用skipWaiting强制跳过等待。

sw.min.js:

self.addEventListener('install', function(event) {
    event.waitUntil(self.skipWaiting()) //这样会触发activate事件
});

虽然文档中说self.skipWaiting这个函数可以插队,直接强制退休旧版本,但是具体实验后,发现如果一个域名下有多个标签页,在edge、chrome上面仍然还需要等待一小段时间,在safari和firefox上面则能够很快的替代旧版本。(这个可以在开发者工具——应用程序——服务工作进程看到当前网站的sw进程)

所以这种方式用来直接更新本地缓存是不行的。

就算一执行serviceWorker.register就能强制替换旧版本,一打开网页的时候仍然还是会使用的cache缓存中的资源(需要再次刷新才能使用最新的资源)。

原因是serviceWorker.register 这个就是一个异步执行的js,就算放在页面的最前面,仍然会有一些资源加载在register执行的前面,这些资源如果是之前缓存的,则直接调用缓存,而不是最新的资源。

所以比较好的方式是,等新的sw安装成功后,提示用户需要刷新一下浏览器,以便更新本地缓存

可以通过浏览器提供的这个函数监听新的sw版本是否安装完成:

navigator.serviceWorker.addEventListener('controllerchange', function (ev) {
    //出现提示条,提示点击刷新页面,更新本地缓存
});

我上面的做法是,用户就算不点击提示条,也会安装新版本的sw,只是已经当前的页面加载了旧版本的缓存,但是用户下次再次进入页面(或者手动重刷页面)也就是最新的了(尽管没有点击提示条)。

目录
相关文章
|
5月前
|
缓存 NoSQL Java
SpringBoot实现缓存预热的几种常用方案
SpringBoot实现缓存预热的几种常用方案
|
13天前
|
消息中间件 canal 缓存
项目实战:一步步实现高效缓存与数据库的数据一致性方案
Hello,大家好!我是热爱分享技术的小米。今天探讨在个人项目中如何保证数据一致性,尤其是在缓存与数据库同步时面临的挑战。文中介绍了常见的CacheAside模式,以及结合消息队列和请求串行化的方法,确保数据一致性。通过不同方案的分析,希望能给大家带来启发。如果你对这些技术感兴趣,欢迎关注我的微信公众号“软件求生”,获取更多技术干货!
48 6
项目实战:一步步实现高效缓存与数据库的数据一致性方案
|
21天前
|
canal 缓存 NoSQL
Redis缓存与数据库如何保证一致性?同步删除+延时双删+异步监听+多重保障方案
根据对一致性的要求程度,提出多种解决方案:同步删除、同步删除+可靠消息、延时双删、异步监听+可靠消息、多重保障方案
Redis缓存与数据库如何保证一致性?同步删除+延时双删+异步监听+多重保障方案
|
2月前
|
缓存 NoSQL 网络安全
【Azure Redis 缓存】在Azure Redis中,如何限制只允许Azure App Service访问?
【Azure Redis 缓存】在Azure Redis中,如何限制只允许Azure App Service访问?
|
2月前
|
缓存 前端开发 Java
【Azure 应用服务】App Service 使用Tomcat运行Java应用,如何设置前端网页缓存的相应参数呢(-Xms512m -Xmx1204m)?
【Azure 应用服务】App Service 使用Tomcat运行Java应用,如何设置前端网页缓存的相应参数呢(-Xms512m -Xmx1204m)?
|
2月前
|
缓存 NoSQL Redis
【Azure Redis 缓存】Redis的指标显示CPU为70%,而Service Load却达到了100%。这两个指标意义的解释及如何缓解呢?
【Azure Redis 缓存】Redis的指标显示CPU为70%,而Service Load却达到了100%。这两个指标意义的解释及如何缓解呢?
|
2月前
|
缓存 NoSQL Java
【Azure Redis 缓存】云服务Worker Role中调用StackExchange.Redis,遇见莫名异常(RedisConnectionException: UnableToConnect on xxx 或 No connection is available to service this operation: xxx)
【Azure Redis 缓存】云服务Worker Role中调用StackExchange.Redis,遇见莫名异常(RedisConnectionException: UnableToConnect on xxx 或 No connection is available to service this operation: xxx)
|
3月前
|
缓存 人工智能
通用研发提效问题之女娲的缓存方案,体现易用性的四重境界,如何解决
通用研发提效问题之女娲的缓存方案,体现易用性的四重境界,如何解决
|
3月前
|
缓存 JavaScript 前端开发
Web Workers与Service Workers:后台处理与离线缓存
Web Workers 和 Service Workers 是两种在Web开发中处理后台任务和离线缓存的重要技术。它们在工作原理和用途上有显著区别。
47 1
|
4月前
|
缓存 NoSQL Java
案例 采用Springboot默认的缓存方案Simple在三层架构中完成一个手机验证码生成校验的程序
案例 采用Springboot默认的缓存方案Simple在三层架构中完成一个手机验证码生成校验的程序
95 5