google workbox webpack plugin to fetch from cache first before service worker

Question

When I just use pre-cache from Workbox Plugin, the service worker try to fetch from indexdb instead of cache(browser-cache).

Yes, service worker is faster than fetching from server. However, if it fetches from memory it takes 0 second.

I have seen all the strategies from workbox but it does not have a strategy that try to fetch from memory first.

This is everything for pre-cache.

new WorkboxPlugin.GenerateSW({
      skipWaiting: true,
      importWorkboxFrom: 'local',
})

service-worker.js

importScripts("/dist/workbox-v3.6.3/workbox-sw.js");
workbox.setConfig({modulePathPrefix: "/dist/workbox-v3.6.3"});

importScripts(
  "/dist/precache-manifest.4b8be844a396ff2fc7335cebbab35f10.js"
);

workbox.skipWaiting();

/**
 * The workboxSW.precacheAndRoute() method efficiently caches and responds to
 * requests for URLs in the manifest.

 */
self.__precacheManifest = [].concat(self.__precacheManifest || []);
workbox.precaching.suppressWarnings();
workbox.precaching.precacheAndRoute(self.__precacheManifest, {});

Answer 1

You can't control how the request is served by the browser cache or the server, so you can't unfortunately first try browser cache, then Cache API, then server.

However, you can try to load both from Cache API and server (including browser cache) at the same time, and serve whichever gave an the fastest answer.

That's what Jake Archibald named "Cache & network race" in his Offline Cookbook: https://jakearchibald.com/2014/offline-cookbook/#cache-network-race

Answer 2

Just to clarify - Workbox tracks a hash of the files in indexedDB, but it doesn't use indexedDB to serve the file. It uses the Cache API to store and retrieve the files.

In your question you mix, Cache, memory, and service worker in terms of where a response is coming from. So to clarify that a little bit:

1. If you have a service worker registered for a page (i.e. the service worker controls the page), then all network requests will first go to the service worker.
2. The service worker can either come up with a response by any means, or it can go to the network (see service worker response section).
3. Once it goes to the network, the browser can decide where it gets its response (see browser response section).

Service Worker Response

The service worker will generally do one of three things to create a response:

1. Use a response from the Cache API to return.
2. Get a response from the network and return it (possibly adding it to the cache).
3. Generate a custom response using any number of sources including static strings, streams, Cache API responses and network responses.

Notice in this list I refer to the Cache API. This is a response cached by a web app that is stored on the users machines.

Browser Response

For any network responses the browser can do one of the following to get a response:

1. Go to the network and get a new response from the server
2. Reference the HTTP cache to return a response

The HTTP cache is separate from the Cache API. It's out of a developers control and can't be relied upon. The browser does what it feels is best.

Workbox + Service Worker

Workbox provides a set of utilities to make the "Service Worker Response" part easier to work with and develop for. This means it's only dealing with the three response types I've outlined.

I've noted down what workbox precaching does and how it works, including what indexedDB is used for in precaching: https://developers.google.com/web/tools/workbox/modules/workbox-precaching