Couple of things are mixed up here. 1) You may instruct a developer that they should clear their caches in Chrome DevTools. Good luck telling that to my father

Couple of things are mixed up here. 1) You may instruct a developer that they should clear their caches in Chrome DevTools. Good luck telling that to my father, who will have no clue what you are talking about. Cache invalidation is not only a technical issue, it affects the user experience, and should be an active part of your design. If your low-level tool does not support it, you need to be aware of that, and should write the code that does support it. 2) Automatically regenerating the serviceworker is the minimum you shall do, but there are other error scenarios that may happen: - You accidentally cache hundreds of 10MBs assets, taking up a huge space of your users. You roll out the new version, these assets are no longer cached, but unless you evict them actively, they will still take up space on the user's computers. - A cache request fails (for whatever reason), and one of the 29 assets goes missing in the cache. The app may be able to run offline, except that it will not show an icon, or will not run an asynchronously loaded script. - A cache update may fail during re-populating the cache (e.g. computer powered off), and the next time the offline app is loaded, the cache stores a mixture of old and new assets. 3) There are several layers of caches between the pixels and the server assets (to name a few: CDNs, web proxies, browser's disk cache, service worker's cache). Being aware that any of them may produce a different version of the same resource will usually help you to design a better tolerance for the edge cases.