Cache Management

We updated our service worker so it caches the main resources the app uses, but what do you do when you update your app? How do you get the new versions of the app’s resources into the cache? In this section, we discuss strategies for managing your local cache before we get back into caching strategies in the sections that follow.

The first question we must answer as we address the issue of cache management is, How can the app recognize that there’s a new version of the web app? In Chapter 2, “Web App Manifest Files,” I mentioned that the browser downloads the service worker every time you reload the app and checks to make sure it is the same as the one currently installed in the browser. If it’s different (if it changes by at least one byte), the browser parses the service worker, executes it, and completes the installation and activation process for the downloaded service worker. This process gives us a useful option: at the top of the service worker file, add a simple variable or constant like this:

Click here to view code image

// service worker version number
const SW_VERSION = 1;

This constant defines a simple service worker version identifier, and when you publish a new version of the app, you simply increment this value. With that in place, the browser detects the new service worker version, installs the updated service worker, and rebuilds the cache with the new resources for the app.

What if the new app version uses different file names for app resources? What do you do now? Well, one option is to simply cache the new resources and ignore the old ones using the code we already have in place in Listing 4.1. The problem with that approach is that you’ll be caching data you’ll never need again, and that’s wasteful (especially on mobile devices).

Thinking out loud here for a while (no changes for you to make to the app), you could delete the cache using something like the following:

Click here to view code image

caches.delete('pwa-learn-cache').then(() => {
  console.log('SW: Cache deleted');
  // do something else here...

});

From the service worker lifecycle, we know that the current service worker is active and still using this cache. If we delete the cache under the current service worker, who knows what would happen (probably something bad). No, there must be a better way.

You could extend the earlier example to something like this:

Click here to view code image

// service worker version number
const SW_VERSION = 1;
// generates a custom cache name per service worker version
const CACHE_NAME = `pwa-learn-cache-v${SW-VERSION}`;

This generates a custom name for each app cache version: pwa-learn-cache-v1, pwa-learn-cache-v2, pwa-learn-cache-v3, and so on. Every time the swVersion value changes, the code generates a new cacheName and therefore a new cache. This requires a small change to the service worker’s install event handler, replacing the original version’s

caches.open('pwa-learn-cache')

with

caches.open(CACHE_NAME)

Here’s the complete listing for the new event handler:

Click here to view code image

self.addEventListener('install', event => {
  console.log(`SW: ${event.type} event fired`);
  event.waitUntil(
    // create a local cache for our app resources
    caches.open(CACHE_NAME)
      // once it's open...
      .then(cache => {
        console.log('SW: Cache opened');
        // cache all of resources from the array
        return cache.addAll(urlList);
      })
      .catch(error => {
        console.error(error);
      })
  );
});

Well, this gets us part way there. We’ve created and populated a new cache for this new service worker version, but we left behind the previous cache. This would work, but we’re still leaving around cached files we’ll never use again. Users would never notice, but it would bother me.

OK, so what do we do? Well, the service worker activate event fires after the service worker installs and just as the service worker becomes the active service worker. At this point, the previous service worker is no longer active, so this seems like a perfect place for us to clean up the earlier cache. The following code shows an updated service worker activate event that deletes all caches that don’t match the name of the current service worker’s cache:

Click here to view code image

self.addEventListener('activate', event => {
  // fires after the service worker completes its installation.
  // it's a place for the service worker to clean up from
  // previous service worker versions
  console.log(`SW: ${event.type} event fired`);

  // don't complete the activation until all the code runs
  event.waitUntil(
    // get the list of cache keys (cache names)
    caches.keys().then(cacheList => {
      // don't stop until all complete
      return Promise.all(
        cacheList.map(theCache => {
          // is the cache key different than the
          // current cache name?
          if (CACHE_NAME !== theCache ) {
            // if yes, then delete it.
            return caches.delete(theCache);
          }
        })
      );
    })
  );
});

The problem with this code is that it whacks all caches except for the current one used by the service worker. That’s fine if the app has only one cache, but if the app opened other caches, this process would delete all caches except for the only one the service worker cares about.

In the following example, I added a CACHE_ROOT constant the service worker uses to build the cache name. We can use this to identify all versions of the service worker cache separately from all others:

Click here to view code image

// service worker version number
const SW_VERSION = 1;
// the root name for our cache
const CACHE_ROOT = 'pwa-learn-cache'
// generates a custom cache name per service worker version
const CACHE_NAME = `${CACHE_ROOT}-v${SW_VERSION}`;

All it requires is a slight change to the if statement buried deep within the activate event listener:

Click here to view code image

if ((CACHE_NAME !== theCache) && (theCache.startsWith(CACHE_ROOT))) {

Here’s the complete listing for the event listener:

Click here to view code image

self.addEventListener('activate', event => {
  // fires after the service worker completes its installation.
  // it's a place for the service worker to clean up from previous
  // service worker versions
  console.log(`SW: ${event.type} event fired`);
  // don't complete the activation until all the code runs
  event.waitUntil(
    // get the list of cache keys (cache names)
    caches.keys().then(cacheList => {
      // don't stop until all complete
      return Promise.all(

        cacheList.map(theCache => {
          // is the cache key different than the
          // current cache name and has the same root?
          if ((CACHE_NAME !== theCache) && (theCache.startsWith(CACHE_ROOT))) {
            // if yes, then delete it.
            console.log(`SW: deleting cache ${theCache}`);
            return caches.delete(theCache);
          }
        })
      );
    })
  );
});

With this in place, the service worker creates a new cache during the install event and whacks all its older caches during the activate event, leaving other caches alone.

Listing 4.2 shows the complete code listing for this updated service worker. Take a moment to update the app’s service worker with the code shown in Listing 4.2 and check it out. Make sure to check the contents of the local cache in the browser’s Developer Tools (refer to Figure 4.3) to validate correct operation.

// service worker version number
const SW_VERSION = 1;
// the root name for our cache
const CACHE_ROOT = 'pwa-learn-cache';
// generates a custom cache name per service worker version
const CACHE_NAME = `${CACHE_ROOT}-v${SW_VERSION}`;

var urlList = [
  '/',
  '/app.webmanifest',
  '/index.html',
  '/css/custom.css',
  '/img/bing-logo.png',
  '/js/index.js',
  '/js/sw-reg.js',
  '/js/utils.js',
];

self.addEventListener('install', event => {
  console.log(`SW: ${event.type} event fired`);
  // the service worker is installing, so it's our chance
  // to setup the app. In this case, we're telling
  // the browser to wait until we've populated the cache
  // before considering this service worker installed
  event.waitUntil(
    // create a local cache for our app resources
    caches.open(CACHE_NAME)

      // once it's open...
      .then(cache => {
        console.log('SW: Cache opened');
        // cache all of resources from the array
        return cache.addAll(urlList);
      })
      .catch(error => {
        console.error(error);
      })
  );
});

self.addEventListener('activate', event => {
  // fires after the service worker completes its installation.
  // it's a place for the service worker to clean up from previous
  // service worker versions
  console.log(`SW: ${event.type} event fired`);
  // don't complete the activation until all the code runs
  event.waitUntil(
    // get the list of cache keys (cache names)
    caches.keys().then(cacheList => {
      // don't stop until all complete
      return Promise.all(
        cacheList.map(theCache => {
          // is the cache key different than the
          // current cache name and has the same root?
          if ((CACHE_NAME !== theCache) &&
            (theCache.startsWith(CACHE_ROOT))) {
            // if yes, then delete it.
            console.log(`SW: deleting cache ${theCache}`);
            return caches.delete(theCache);
          }
        })
      );
    })
  );
});

self.addEventListener('fetch', event => {
  console.log(`SW: ${event.type} ${event.request.url}`);
  // fires whenever the app requests a resource (file or data)
  event.respondWith(
    // check to see if it's in the cache
    caches.match(event.request)
      .then(response => {
        // if it is, then return the cached response
        // object from the cache
        if (response) {

          console.log(`SW: Return Cache ${event.request.url}`);
          return response;
        }
        // otherwise, tell the browser to go get the
        // resource from the network
        console.log(`SW: Return Network ${event.request.url}`);
        return fetch(event.request)
      })
  );
});

Return a Data Object on Error

In the app’s current state, when the browser can’t fetch news data from the server, the page displays the generic error highlighted above the footer in Figure 4.6. The app knows it received an error retrieving the data, so it correctly updates the status in the bottom-right corner of the page, but we can do better. Since we have a service worker working on our behalf, let’s let it manage dealing with the fetch error.

What we want to do is to make the service worker return an empty data set plus the error code the app needs to update the footer. To do this, first add the following constant to the top of the project’s public/sw.js file:

Click here to view code image

const EMPTY_NEWS_OBJECT = {
  "status": 3,
  "lastUpdated": 0,
  "items": []
};

What this does is create a generic results object the service worker serves up when it can’t fetch the data live from the server. Next, update the fetch event listener so it deals differently with data requests than with the other resources used by the app. Start by refactoring the existing event listener so it looks like the following:

Click here to view code image

self.addEventListener('fetch', event => {
  console.log(`SW: ${event.type} ${event.request.url}`);
  // is the request for news data?
  if (event.request.url == `${location.origin}/api/news`) {
    console.log('SW: Data request detected');

  } else {
    // non-data request, so respond with fetch results
    event.respondWith(
      // check to see if it's in the cache
      caches.match(event.request)
        .then(response => {
          // if it is, then return the cached response
          // object from the cache
          if (response) {
            console.log(`SW: Return Cache ${event.request.url}`);
            return response;
          }
          // otherwise, tell the browser to go get the
          // resource from the network
          console.log(`SW: Return Network ${event.request.url}`);
          return fetch(event.request);
        })
    );
  }
});

The if clause checks to see whether the requested resource is the call to the server’s News API. The else clause includes the original code from the initial event listener. If you load the app now, it should work exactly as it did before, even when offline, as all we’ve really done is add a log item for the special data case.

Now, in the event listener’s if clause, after the log item, copy in the following code:

Click here to view code image

event.respondWith(
  // then see if you can get the data
  fetch(event.request)
    // oops, error, can't complete the fetch
    .catch(() => {
      // return the empty news object
      return new Response(JSON.stringify(EMPTY_NEWS_OBJECT),
        { "status": 200, "statusText": "Dummy data!" });
    })
);

The code tries to get the data from the server; if it can’t, the catch method kicks in and responds with the empty news object we added at the top of the file. Now when you try to load the page while offline, you’ll get the friendlier message already built into the app, as shown in Figure 4.7.

Here’s the complete source code listing for the new event handler:

Click here to view code image

self.addEventListener('fetch', event => {
  console.log(`SW: ${event.type} ${event.request.url}`);
  // is the request for news data?
  if (event.request.url == `${location.origin}/api/news`) {
    console.log('SW: Data request detected');
    event.respondWith(
      // then see if you can get the data
      fetch(event.request)
        // oops, error, can't complete the fetch
        .catch(() => {
          // return the empty news object
          return new Response(JSON.stringify(EMPTY_NEWS_OBJECT),
            { "status": 200, "statusText": "Dummy data!" });
        })
    );
  } else {
    // non-data request, so respond with fetch results
    event.respondWith(
      // check to see if it's in the cache

      caches.match(event.request)
        .then(response => {
          // if it is, then return the cached response
          // object from the cache
          if (response) {
            console.log(`SW: Return Cache ${event.request.url}`);
            return response;
          }
          // otherwise, tell the browser to go get the
          // resource from the network
          console.log(`SW: Return Network ${event.request.url}`);
          return fetch(event.request);
        })
    );
  }
});

You can easily tweak this code to deliver a different data object for each type of data request.

The complete service worker code for this example is in the project folder’s publicservice-workerssw-43.js file.

Adding an Offline Page

At the beginning of this chapter, I omitted the app’s other pages, About and Feedback, from the list of cached resources. I did this not because I hate those pages but because I needed some pages to not be available offline for this section of the chapter.

When you take the browser offline and try to load the About or Feedback page, you’ll see an error page like the one shown in Figure 4.8. This isn’t the best experience for the user, as it’s a stark change from the look and style of our app and doesn’t say much about what really happened. The browser tries to explain some of the possible causes for the current error condition but fails rather spectacularly.

We, on the other hand, know a lot more about why the pages didn’t appear and can give the user a better experience through service workers. There are a lot of different options for doing this, ranging from simple to complex. I’ll highlight a few here and leave it up to you to figure out some others.

One option is to use the approach taken in the previous section and return custom content whenever a fetch request fails. Rather than return a data object as we did in the previous section, you return text or HTML content.

Here’s an example of a fetch event listener that does just that:

Click here to view code image

self.addEventListener('fetch', event => {
  console.log(`SW: ${event.type} ${event.request.url}`);
  event.respondWith(
    // check to see if it's in the cache
    caches.match(event.request)
      .then(response => {
        // if it is, then return the cached response
        // object from the cache
        if (response) {
          console.log(`SW: Return Cache ${event.request.url}`);
          return response;
        }
        // otherwise, tell the browser to go get the
        // resource from the network
        console.log(`SW: Return Network ${event.request.url}`);
        return fetch(event.request)
        .catch(() => {

          return new Response("Hmmm, I can't seem to access that page.");
        })
      })
  );
});

In this case, when the fetch fails, the code creates a new Response object with the content and returns it as the response for the fetch operation. When you try this in a browser in offline mode, you get the page shown in Figure 4.9.

Now, you can get fancy and return HTML in the response; the affected portion of the code would look like this:

Click here to view code image

return fetch(event.request)
  .catch(() => {
    return new Response(
      "<!DOCTYPE html><html><body>" +
      "<h1>Access Error</h1>" +
      "<p>Hmmm, I can't seem to access that page.</p>" +
      "</body></html>",
      { headers: { "Content-Type": "text/html" } }
    );
  })

The code returns an HTML page to the browser, but the browser doesn’t recognize it as an HTML page until you add the headers as a parameter when creating the response object. When you load the page in an offline browser, you get a slightly better experience because the resulting page has a formal heading and some styling around the body, as shown in Figure 4.10.

Now, you can spruce the content up with styling and other bells and whistles, but you’re still generating HTML on the fly in your service worker, and that’s not efficient. Another issue is that this is a rather brute-force approach, as it affects any requested resource even though the browser is already quite capable of dealing with missing images, CSS files, and other stuff. What we need is something that returns HTML only when the request says it can handle HTML, like this:

Click here to view code image

if (event.request.headers.get('accept').includes('text/html')) {
  // do something cool

}

Here’s a full implementation with the accepts check and generated HTML content:

Click here to view code image

return fetch(event.request)
  .catch(() => {
    if (event.request.headers.get('accept').includes('text/html')) {
      return new Response(
        "<!DOCTYPE html><html><body>" +
        "<h1>Access Error</h1>" +
        "<p>Hmmm, I can't seem to access that page.</p>" +
        "</body></html>",
        { headers: { "Content-Type": "text/html" } }
      );
    }
  })

This approach limits when the service worker responds with HTML, but we’re still sending generated HTML. What we should do is send a custom HTML page that looks like the rest of our site. We’ve already cached the site’s CSS file, so all we need to do is add the page we want returned when the app is offline, or the browser can’t locate the page.

The app already has this offline page located at the project’s publicoffline.html. Let’s add the file to the cache using a slightly different approach. First, add the following line to the top of the project’s sw.js file:

const OFFLINE_PAGE = '/offline.html';

This creates a reference to the offline file we’ll use when we serve it up when a resource can’t be found. Next, update the urlList array by adding OFFLINE_PAGE as the last item in the array:

Click here to view code image

var urlList = [
  '/',
  '/app.webmanifest',
  '/index.html',
  '/css/custom.css',
  '/img/bing-logo.png',
  '/js/index.js',
  '/js/sw-reg.js',
  '/js/utils.js',
  OFFLINE_PAGE
];

With this in place, the app knows about the offline file and will cache it during service worker installation. Finally, in the fetch event listener, add the following code to the end of the event listener when the service worker knows the resource isn’t in the cache:

Click here to view code image

return fetch(event.request)
  .catch(() => {
    if (event.request.headers.get('accept').includes('text/html')) {
      return caches.match(OFFLINE_PAGE);
    }
  })

At this point, the service worker has given up; it knows the requested resource isn’t in the cache, and it tried to fetch it from the network and failed. All that’s left to do is serve up the offline file if it happens to be in the cache. Here’s the complete event listener code:

Click here to view code image

self.addEventListener('fetch', event => {
  console.log(`SW: ${event.type} ${event.request.url}`);
  // is the request for news data?
  if (event.request.url == `${location.origin}/api/news`) {
    console.log('SW: Data request detected');
    event.respondWith(
      // then see if you can get the data
      fetch(event.request)
        // oops, error, can't complete the fetch
        .catch(() => {
          // return the empty news object
          return new Response(JSON.stringify(EMPTY_NEWS_OBJECT),
            { "status": 200, "statusText": "Dummy data!" });
        })
    );
  } else {
    // non-data request, so respond with fetch results
    event.respondWith(
      // check to see if it's in the cache
      caches.match(event.request)
        .then(response => {
          // if it is, then return the cached response
          // object from the cache
          if (response) {
            console.log(`SW: Return Cache ${event.request.url}`);
            return response;
          }
          // otherwise, tell the browser to go get the
          // resource from the network
          console.log(`SW: Return Network ${event.request.url}`);
          return fetch(event.request)
            .catch(() => {
              if (event.request.headers.get('accept')

                .includes('text/html')) {
                return caches.match(OFFLINE_PAGE);
              }
            })
        })
    );
  }
});

Bring the app back online, reload the page in the browser, then go offline again. When you try to load the About page while the browser is offline, you get the much prettier page, shown in Figure 4.11, which includes the app header, menu, and footer, just like the rest of the app’s pages. This is a much better user experience, don’t you agree?

The complete service worker code for this example is in the project folder’s publicservice-workerssw-44.js file.

Cache-Only

For an installed PWA, especially simple apps such as the Tip Calculator from Chapter 2, the app is entirely static; there’s no dynamic content in the app. You can easily build a URL array into the service worker and use it to cache all app resources at startup, as I showed in an earlier example. With that in place, the app works regardless of whether the browser has network connectivity.

In the PWA News app, only parts of the app rarely change. To enable the app to run even if the device running the app doesn’t have network connectivity, you can update the urlList array from our recent service worker examples to contain every possible static resource needed by the app. With that in place, you can implement the cache-only approach highlighted in the following fetch event listener:

Click here to view code image

self.addEventListener('fetch', event => {
  console.log(`SW: ${event.type} ${event.request.url}`);
  // fires whenever the app requests a resource (file or data)
  event.respondWith(
    // check to see if it's in the cache
    caches.match(event.request)
      .then(function (response) {
        // if it is, then return the cached response
        // object from the cache
        if (response) {
          console.log(`SW: Return Cache ${event.request.url}`);
          return response;
        }
      })
  );
});

If the resource isn’t in the cache, the code does nothing; the service worker lets the browser deal with its failure. In this case, the browser displays the generic resource-not-found error page shown in Figure 3.8. You can add an offline file to the resource array, as shown in an earlier example, which is needed only if you forget to put a file in the resource array. The fetch event listener code looks like the following:

Click here to view code image

self.addEventListener('fetch', event => {
  console.log(`SW: ${event.type} ${event.request.url}`);
  // fires whenever the app requests a resource (file or data)
  event.respondWith(
    // check to see if it's in the cache
    caches.match(event.request)
      .then(function (response) {
        // if it is, then return the cached response
        // object from the cache
        if (response) {
          console.log(`SW: Return Cache ${event.request.url}`);
          return response;
        }
        // otherwise check to see that the request accepts HTML
        if (event.request.headers.get('accept').includes('text/html')) {
          // then return the offline page
          console.log(`SW: serving offline page ${OFFLINE_PAGE}`);
          return caches.match(OFFLINE_PAGE);
        }
      })
  );
});

For this approach, I had to make sure every file the app needed to run was in the cache. What caused me the most pain was figuring out that I also needed the service worker file even though it was already installed. Remember, the browser requests the service worker file every time the page loads, regardless of whether the service worker changed.

The complete service worker code for this example is in the project folder’s publicservice-workerssw-45.js file.

Network First, Then Cache

For many apps, especially ones that display dynamic data, you want the app to always pull content from the network if possible, then fall back to the cache when the device running the app is offline.

Like the cache-only example from the previous section, with this approach, you build the list of static resources and use it to populate the cache at service worker activation. The service worker attempts to pull requested resources from the network and serves them from the cache if the network version is not available.

For dynamic sites, your cache of local files is a little different. What you need in the cache is all the resources required to render the app UI plus cached data or some extra content to explain why there’s no data. You can spoof the data as we did earlier in the chapter, or, in the next chapter, I’ll show you how to cache data for offline use.

With the list of cached resources in place, the following fetch event listener shows how to implement a network-first, cache-next approach:

Click here to view code image

self.addEventListener('fetch', event => {
  console.log(`SW: ${event.type} ${event.request.url}`);
  // fires whenever the app requests a resource (file or data)
  event.respondWith(
    // try to get the file from the network
    fetch(event.request)
      .catch(() => {
        // rats, network resources are not available
        // do we have it in the cache?
        console.log(`SW: Trying Cache ${event.request.url}`);
        return caches.match(event.request)
          .then(response => {
            // if it is, then return the cached response
            // object from the cache
            if (response) {
              console.log(`SW: Return Cache ${event.request.url}`);
              return response;
            }
          })
      })
  );
});

The complete service worker code for this example is in the project folder’s publicservice-workerssw-46.js file.

Network First, Update Cache

In all the examples so far, the cache we used was static, populated during service worker installation and never updated again. That’s not very exciting, is it? This approach forces the service worker to manually rebuild the cache with every version, even if the file didn’t change or wasn’t used again.

Another approach is to let the service worker build the cache as the app runs, automatically populating the cache with every resource requested by the app. This one’s a little tricky, so hold on while I lay it all out for you.

For the Tip Calculator app from Chapter 2, this is the perfect caching strategy. Every request the app makes is automatically cached. So, if you install the app or later try to hit the app while the device is out of network connectivity, the app will load, in its entirety, from cache.

When I implemented this caching strategy for the PWA News app, I was a little worried about the app’s news data. The way that Bing structures its news results, the data comes back as a JSON object with URLs pointing to any images associated with the articles (typically thumbnail images). I didn’t want to cache those images because they’d change with every news update and I didn’t want to fill up the cache with unused images, nor did I want to figure out a way to clean them up either.

As I tested the code I’ll share with you in a minute, I noticed that everything was taken care of automatically for me. Woohoo! Let me explain.

The following code implements a service worker fetch event listener that caches every request made by the server. What I found in my testing was that it cached every resource request, even the API request to the server to retrieve new data. What it didn’t do was cache the image files—automatically, not because I did anything special to make that happen. Not only did it not cache the image files for me, the web app still displayed the image files for me when I disabled the network and reloaded the page. Surprised? Yeah, me too. Take a moment to look through the code, and I’ll explain everything on the other side.

Click here to view code image

self.addEventListener('fetch', event => {
  console.log(`SW: ${event.type} ${event.request.url}`);
  // fires whenever the app requests a resource (file or data)
  event.respondWith(
    // try to get the file from the network
    fetch(event.request)
      // whew, we got it
      .then(response => {
        // do we have a valid response?
        if (response && response.status == 200) {
          // clone the response; it's a stream, so we can't
          // write it to the cache and return it as well
          let responseClone = response.clone();
          // try to open the cache
          caches.open(CACHE_NAME)
            // if we successfully opened the cache
            .then(function (cache) {
              console.log(`SW: Adding ${event.request.url} to the cache`);
              // then write our cloned response to the cache
              cache.put(event.request, responseClone);
            });
          // return the original response
          return response;
        } else {
          // return whatever error response we got from the server
          return response;
        }
      })
      .catch(() => {
        // rats, network resources not available
        // do we have it in the cache?
        console.log(`SW: Trying Cache ${event.request.url}`);
        return caches.match(event.request)
          .then(response => {
            // if it is, then return the cached response
            // object from the cache
            if (response) {
              console.log(`SW: Return Cache ${event.request.url}`);
              return response;
            }
          })
      })  // catch
  );
});

The complete service worker code for this example is in the project folder’s publicservice-workerssw-47.js file.

All right, for every resource request, this service worker does the following:

• Tries to retrieve the resource from the network.

• If it gets a response, it

  • Checks to see if the response is a valid response and not an error.

  • Clones the response (responses are streams, so the service worker can’t pass a response to the browser and write it to the cache at the same time).

  • Writes the cloned response to the cache.

  • Returns the original response to the requestor.

  • If the response is not an HTTP response of 200 (success), it returns whatever it has to the requestor for the requestor to process the error.

• If it gets an outright error, it

  • Checks the cache to see if it has the resource there.

  • If it does, it returns the cached resource.

  • Otherwise, it does nothing and lets the requestor deal with the problem (usually by showing the page shown in Figure 4.8).

As it processes all of the app’s requests, the requests return with different response types⁵ depending on how the browser views the resource origin based on security settings in the browser and in the app. Remember, service workers are all about security, so if you request a resource that’s not from the same origin as the page requesting the resource, the service worker’s going to complain. The way it complains here is by not caching the resource.

5. https://developer.mozilla.org/en-US/docs/Web/API/Response/type

The service worker checks to see if the response is valid using the following code:

Click here to view code image

if (response && response.status == 200)

Some examples you see online do it this way:

Click here to view code image

if (response && response.status == 200 && response.type == 'basic')

What I learned while testing this code is that the service worker will cache only resources with a type of basic. There’s no need to check the type before caching. All the same origin requests arrive as basic, but the image requests, because their origin is Bing and not the local API server, are ignored and not added to the cache. To prove this, look at Figure 4.12; it shows the complete resource cache generated by this fetch event listener.

I mentioned that when I disabled the network, the news thumbnail image files appeared properly in the app anyway. Why is that? Well, even though I have a service worker managing my cache for me, the browser still respects the cache headers⁶ in the response headers. If you look at a Bing image request response header in Fiddler,⁷ as shown in Figure 4.13, you’ll see that Bing sets a Cache-Control max-age header for the resource in the highlighted portion of the image. This tells the browser it can hold onto the image for 1,209,600 seconds if it wants to.

6. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control

7. https://www.telerik.com/fiddler

So, even though you think the service worker has complete control over the cache, it doesn’t; it has complete control over cache storage, but the browser controls the HTTP cache. If you’re testing away and notice that things aren’t refreshing properly for you, that’s because the browser may be interfering. You may have to clear the browser cache for your latest resources to show.

Now, I’m not saying you couldn’t configure the cross-origin resource sharing (CORS) settings for the app and allow the service worker to cache resources from another origin—you probably can. My point is that this extra security protection worked in my favor as I implemented this service worker caching example.