Implementing Service Workers with an appcache fallback for unsupported browsers

Asked 15/6, 2017 at 14:10 Answered 19/6, 2019 at 18:11

Solved web offline service-worker html5-appcache progressive-web-apps

I'm looking into techniques for building a Progressive Web App in Aurelia with offline functionality that works across the major browsers. Service Workers are seemingly the preferred option for asset caching, but with lack of support in Safari (and currently Edge). Is it possible to use service workers with a fallback to appcache if they're not supported? How will an application behave if there's an appcache manifest AND a service worker installed?

Nonet answered 15/6, 2017 at 14:10 Comment(0)

if a browser supports service workers then the service worker caching will be used instead of the appCache manifest. You can include the appCache manifest for legacy browsers like Safari and things will work the way they did in the past. Plus for modern browsers they will leverage service worker caching and act as if the appCache does not exist. Sort of like the way responsive images work.

Zyrian answered 16/6, 2017 at 14:16 Comment(3)

+1 this library for gulp follows that philosophy: github.com/arcturus/gulp-sww It creates all the serviceworker files to cache your website but also creates the appcache code needed to fallback. Here is the code for detecting the serviceworker installation of doing the fallback to appcache: github.com/arcturus/gulp-sww/blob/master/templates/unminified/… – Auden 29/6, 2017 at 17:12

Be advised that even though the appcache is ignored, Chrome still downloads and updates the appcache after the SW registers. (That's been an open bug since 2014, so don't hold your breath.) crbug.com/410665 – Ceroplastics 22/10, 2017 at 15:52

good to know! I know appCache is in the process of being deprecated by most browsers. I think next year sometime is the target, but that could vary. – Zyrian 26/10, 2017 at 13:22

The check which technology the browser is supporting is easly done:

if(navigator.serviceWorker){
    initServiceWorker()
}else if(window.applicationCache){
    initApplicationCache();
}else{
    console.log('no caching possible');
}

Dynamic loading a service worker should not be a problem since it is done in javascript anyway.

Dynamic loading applicationCache's mainfest seems not to be possible, but you can try an iframe hack, see: Dynamically Trigger HTML5 Cache Manifest file?

Gameto answered 16/6, 2017 at 9:51 Comment(0)

It's 2019 and iPhone still doesn't get the service worker functioning in WebViews. So a application cache fallback is still useful.

It's not exactly true that app cache will have no effect when service worker is up. It still tries to update its cache which is a silly thing to do. Turning it off isn't crucial but would be good thing to do.

The trick I'm doing now to disable app cache when service worker is functioning, is by intercepting the html (navigation) request and just remove the manifest attribute from <html>.

Something like this in the service worker script:

self.addEventListener('fetch', (ev) => {
  if (request.mode === 'navigate' && request.method === 'GET') {
    ev.respondWith(
      fetch(ev.request.url)
        .then(r => r.text())
        .then(html => new Response(html.replace('manifest=', 'xmanifest='), {
          headers: {'Content-Type': 'text/html'}
        }))
    )
  }
})

Rheology answered 19/6, 2019 at 18:11 Comment(1)

This looks like a nice solution on the first look I just noticed one problem. On the first load the manifest is still loaded and the chache will be filled because the serviceworker is not yet registered – Pockmark 4/6, 2020 at 8:39

Recommended topics

Hot tags