Caching strategies in Progressive Web Apps

Going offline with PWA

Caching is very important feature associated with Progressive Web Apps. It is useful especially when offline availability of the app is one of the requirements. Unfortunately, not all web browsers allows to use it at the moment as this feature requires service worker script. You can track service worker support status on this site. While waiting for Safari and Edge support we can already use it on Chrome and Firefox.

It may be not so obvious why offline mode is needed for some apps – it is quite usual that web app features are heavily depending on remote services (web APIs). However, PWA approach doesn’t require to implement full functionality in offline mode. It’s all about the user experience – you can start by making sure your app UI will be available in offline mode. It’s much better than displaying 404 error.

Setup cache in service worker

Before we can start caching our page we need to define a new cache. We should start by creating a new javascript file named sw.js. Next step is to register it our web app:

if ('serviceWorker' in navigator) {
    navigator.serviceWorker.register('sw.js');
}

The if statement is necessary make sure this code doesn’t break on older browser that doesn’t support service workers.

Last step is to setup a cache, defining which resources should be cached there. It is a best practice to set it up on service worker install event:


var STATIC_CACHE = 'my-static-cache';

self.addEventListener('install', function(event) {
    event.waitUntil(
        caches.open(STATIC_CACHE).then(function(cache) {
            return cache.addAll([
                '/js/jquery.min.js'
            ]);
        })
    );
});

Typical cache strategies

Two web browser supplier companies, which are Google and Mozilla, are supporting developers with great documentations related to Progressive Web Apps and Service Workers. We can find in these documentation examples of typical cache strategies:

  • Cache only
    • Designed to serve only cached resources. Use case: for alway-static content, e.g. 3rd party libraries, static JSON files.
  • Network only
    • Always fetch from a server (default browser behavior). Use case: for always-online content.
  • Cache falling back to network
    • At first try to load resource from cache, if failed then fetch from a server. Use case: for offline-first applications with some static content stored in cache.
  • Network falling back to cache
    • At first try to fetch resource from a server, if failed then load from cache. Use case: for frequently changing resources, e.g. articles, profile details, currency rates.
  • Cache then network
    • Load resource from cache initially, but also perform fetch from a server and display fresh data as soon as it’s retrieved. Use case: for frequently changing resources where quick application load is demanded.

You can find learn more and see examples on Google’s introduction to Service Worker development or on Mozilla’s ServiceWorke.rs.

Service Worker toolboxes

In most of the cases, one of strategies mentioned above is suitable. Luckily, there is no need to develop them from scratch each time you start a new project. There are some ready-to-use frameworks supporting you to do that:

  • sw-toolbox – a set of Service Worker tools developed by Google,
  • @angular/service-worker – an Angular package which builds Service Worker script based on json configuration file and bundles it with built application.

1 comment

  1. I think that is one of the most important info for me. And i’m satisfied studying your article.
    But wanna remark on few basic issues, The web site style is great, the articles is in point of fact great : D.
    Excellent task, cheers

Leave a Reply

Your email address will not be published. Required fields are marked *