I’m trying to make a Progressive Web App! Part 3.3: Update assets

Now, with our assets stored in the cache, the site loads almost instantly for the visitor. This happens because the service worker intercept the request and serves the assets from the cache and not over the network.

But what if we ships an update to style.css or app.js ? If the site never loads them from the server, the user will never get them.
Imagine this pice of CSS:

body {
  background: white;
}

Now we wanna change the background to a light grey color:

body {
  background: #eaeaea;
}

The users that already have style.css stored in the cache will be stuck with the white background. Unless…

Update cache in the background

Remember this code from the last part?

// service-worker.js
self.addEventListener('fetch', function (event) {
  event.respondWith(fromCache(event.request));
}

Inside this event listener, we can also tell our service worker to update the assets in the background.
Add the following function to service-worker.js :

var update = function (request) {
  return caches.open(cache_name).then(function (cache) {
    return fetch(request).then(function (response) {
      return cache.put(request, response);
    });
  });
}

And add a call to this function from the event listener:

self.addEventListener('fetch', function (event) {
  event.respondWith(fromCache(event.request));
  event.waitUntil(update(event.request));
}

So what is this?

The fetch event is fired every time the browser is supposed to make a request. One time for style.css and one time for app.js in this case.
When this happens, we send the request object to the update() function. The cache is opened and then the browser will fetch() the resource, style.css for example, and then store it in the cache using cache.put() .

But the background is still white!

Yes. There are two things happening inside the fetch event listener:

1. Replace the network request with assets from the cache instead.
2. Make the network request anyway and receive fresh assets from the server.

Step two happens in the background, when the site already has been loaded with the “old” assets. The user won’t see the new, grey background until the next time he or she visits the site.

It’s like an update to Chrome. The download starts when you open it and start browsing the web, but you won’t browse with the new version until you restart it.

But isn’t this horrible?!

Our project manager and/or client wants that all users should get the new background immediately! Doesn’t they see it until the second visit after we’ve pushed the update?

Well, this is of course something we’re not used to when we think about making an update to a website.
But if we think about it more like an app, it’s not that strange anymore. If Facebook ships an update to their app, the users won’t be using the new version until they…well, updates it.
And websites are becoming more and more like apps. And that is cool!

Disclaimer…

This was the third and final sub-part of part three. All of the service worker code in these three blog posts comes from this excellent resource:

ServiceWorker Cookbook