Service workers and the two caches

Question

I've always assumed (though not seen it explicitly stated) that the following is the path of a HTTPS request when a service worker is installed:

1. The browser encounters an image with a URL. A HTTPS request is initiated.
2. The request passes through the "internal" cache, which will return the resource if it has it, unless "Disable cache" is checked in dev tools.
3. The request is sent as a fetch event to the service worker. There your custom code can query your custom cache and see if the resource has been stored there, and return it. If not you can forward the request to the network. (Not sure if "Disable cache" has any effect here).

Just hoped that someone could confirm that this is how it works.

Answer 1

If with "internal cache" you mean the browser cache, then it is accessed after accessing the Service Worker cache (you need to swap your point 2 with 3).
If you set disable cache , this will affect only the browser cache, not the Service Worker one. The requests reaching this point, meaning no match found in the Service Worker cache, will go straight to the server side.

You can think of the browser cache as a fallback cache when implementing caching strategies with Service Workers.

Below you can find the cache order followed when an HTTP Request is executed.
You can also read the web.dev article , explaining this in detail.

Answer 2

@Francesco linked to an article about service workers and HTTP requests (see graph in his answer). But it turns out that this graph is incomplete. Google Chrome's rendering engine Blink also has a cache that is checked first before a request is passed to the service worker. The devtools setting "Disable cache" disables Blink's cache. Explained here:

What does Blink in-memory cache store?

So in reality there are three caches, and they are passed in this order: 1. Blink's cache, 2. the service worker's cache (if implemented), and 3. the Browser cache. Add to that what ever cache is in the CDN.