While I agree with your process, caching static assets is solved years ago with server-side caching and cache busting works flawlessly for serving new content when it's available without falling back to old ones first. The issue with offline support for SW is that it's all or nothing, and not caching specific assets. That should be handled by the server, not the browser, either way. Let me know if I'm understanding something wrong about SW config :) Thanks for the comment!
While I agree with your process, caching static assets is solved years ago with server-side caching and cache busting works flawlessly for serving new content when it's available without falling back to old ones first. The issue with offline support for SW is that it's all or nothing, and not caching specific assets. That should be handled by the server, not the browser, either way. Let me know if I'm understanding something wrong about SW config :) Thanks for the comment!
Caching using headers is indeed a breeze, but it falls short in two scenarios:
Service workers offer a lower-level caching mechanism that can bypass these limitations.
That said, if you can control your headers and don't plan on offline access (but are caching for perf improvement), headers are the way to go.