Service workers for your PWA (Progressive Web App) website

Two pillars for transforming your website into a PWA (Progressive Web App) are the manifest and having service workers. (Besides that it’s better if your website is responsive, follows PRPL principles, but I won’t go into these in the current blog post.) Manifest is kind of a no brainer, although requires some work. You need to identify the main theme color and main background color for your website, and generate various sizes of the favicon of your website and reference some of those from the manifest and some of them from the header meta section. There are several websites (Example) which help you to generate series of images and the corresponding manifest and HTML meta tags.

On the other hand the service workers are not as evident since your website could take several shapes and forms (for example SPA / non SPA), sub URLs and assets. You first need to decide what caching strategies you prefer and for what part of your website: do you prefer off-line first or on-line first approach. On-line first approach could be a good idea if your website for example displays crypto currency tickers and their current values. In case of a static website with a blog section (like mine) you are good to go with an off-line first approach. Still, you need to configure which files exactly the service worker infrastructure should cache for you for off-line use and what way (expiration, etc.). You can decide the approach per resource basis, so your static website can be off-line first, while only the trade ticker part could be on-line first with an off-line fall-back.

In the past Google provided libraries like sw-precache to help with this configuration task and possibly cut down plumbing code related to the service worker configuration and activation mechanisms. The newest generation of Google’s service worker helper library is Workbox, and that takes the help to a next level and I believe we arrived to a point where the configuration is minimal and painless. Ideally you want to only specify the list of assets (possibly with wildcards) and what strategy you want to follow for each. Then the framework should take care of the rest for you.

Along that line: in case you are using any static site generator framework then there’s a very good chance that your framework has a package which provides a layer on top of Workbox and you can deal with it at the level of your generator framework instead of Workbox’s JavaScript API. A common principle in software engineering is to avoid reinventing the wheel, so you can spend your time with the more meaningful tasks of your project. Unless your framework of choice is very exotic and doesn’t have much community behind it yet, service worker configuration and dealing with Workbox must have been done by thousands of engineers before you, and steps probably taken to make this part seamless. This means: always look how your selected framework supports PWA and look for a layer on top of Workbox.

At the time of this blogpost this site currently uses Jekyll, and I saw two candidates (BTW, multiple choices are usually a good sign of thriving community): jekyll-pwa-plugin or jekyll-workbox-plugin. Both of them seems nice, but according to this blogpost I decided to go with the latter. Since Jekyll is RoR (Ruby on Rails) based framework the "package" you need to install is a Ruby Gem. The configuration is simple, well readable (yaml format), no fluff inside the expected _config.yml, and the few plumbing code placeholders. I only needed to add two JavaScript entries:

In default.html: source

if ('serviceWorker' in navigator) {
  window.addEventListener('load', function() {
    navigator.serviceWorker.register("/sw.js").then(function() {
      console.log("Service Worker Registered");
    });
  });

And a short sw.js file stub (source)

// let Workbox handle our precache list
// NOTE: This will be populated by jekyll-workbox-plugin.
workbox.precaching.precacheAndRoute([]);

And that’s all!