urlsToCache
的情况下缓存来自应用的所有请求。所以我会在fetch
event。最初,
this.addEventListener('fetch', function(event) {
var fetchReq = event.request.clone(),
cacheReq = event.request.clone();
event.respondWith(fetch(fetchReq).then(function(response) {
var resp = response.clone();
caches.open(CACHE_NAME).then(function(cache) {
req = event.request.clone();
cache.put(req, resp);
});
return response;
}).catch(function() {
return caches.match(cacheReq);
}));
});
离线情况得到了很好的处理。但问题在于连接速度慢。用户必须等到获取超时或抛出错误才能从缓存中获取响应。
self.addEventListener('fetch', function(event) {
var cacheRequest = event.request.clone();
event.respondWith(caches.match(cacheRequest).then(function(response) {
if(response) return response;
var fetchRequest = event.request.clone();
return fetch(fetchRequest).then(function(response) {
var responseToCache = response.clone();
caches.open(cache_name).then(function(cache) {
var cacheSaveRequest = event.request.clone();
cache.put(cacheSaveRequest, responseToCache);
});
return response;
});
}));
});
在缓存优先的情况下,提供的响应很好。但这里的问题是当代码更新时。当通过sw提供的/public/main.css
更新时,在页面重新加载时仅提供缓存,不提供更新的内容。
我还尝试从cache-v2
将cache_name修改为cache-v1
(以便存在sw二进制diff并更新sw并清除旧缓存),并在cache-v1
上清除activate
{1}}事件。但它引发了两个服务工作者在同一时间Registration ID
同时运行的新问题。关于这一点的更多内容是在另一个SO问题中:How to stop older service workers?
答案 0 :(得分:6)
同时运行的两名服务人员在技术上不是问题 - 它按设计工作。 (请参阅我对How to stop older service workers?的回答)确保关闭可能使旧版服务工作者处于活动状态的其他选项卡。
您在这里遇到了不同缓存与网络方案之间不可避免的权衡。如果您还没有通读the offline cookbook,那么在尝试确定哪种缓存策略最适合您的特定资源时,这是一个很好的起点。