Re: [ServiceWorker] Pattern for handling fingerprinted assets in cache? (#657)

> If there's asset fingerprinting then there's almost certainly a build process for the site. If that's the case, then modifying the server worker script during the build process is an option, and that modification can include injecting an array of the up to date fingerprinted URLs into the script file.

Unless I misunderstand the point, having the build process inject an array of updated fingerprinted URLs into the serviceworker script assumes an [on install](https://jakearchibald.com/2014/offline-cookbook/#on-install-as-a-dependency) strategy for cache population?

Where as I think the behaviour described by the OP is more like the [stale-while-revalidate](https://jakearchibald.com/2014/offline-cookbook/#stale-while-revalidate) pattern.

Except that in this context, we don't get a *cache hit* that we can respond with, while we go out to the network to revalidate the cached asset.

Rather, we get a *cache miss*, and we want the serviceworker to respond with a *different* cache entry while we go to the network and fetch the missing resource (and later remove that cache entry once the missing resource has successfully fetched/cached).

FWIW, this was the same stumbling block I hit when looking at introducing ServiceWorker to an existing app that uses fingerprinted assets (which led me here to this issue).

Switching to a [cache, falling back to network](https://jakearchibald.com/2014/offline-cookbook/#cache-falling-back-to-network) would work OK with fingerprinted assets; but you lose the ability to provide an early (but stale) response in the event of a cache miss;  and there's still the question of how to cleanup stale cache entries once a newer fingerprinted version of the asset is available in the cache.

---
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/657#issuecomment-155947311