According to the example here:

https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Offline_Service_workers#Installation

".../" and ".../index.html" are two different paths. (It makes sense since / -> /index.html is a server-side convention, and not anything that the browser knows about.)

(Should we do the Updates part as well, though? I've seen some caching being too persistent, but I haven't determined if it's the service worker caching too aggressively, or the CDN being nasty)

If you're running a site with a service worker cache, its expected that you need at least one reload to pull the new content. Any updates to the service worker should trigger the update/install path, but none of the new content can be shown until after the cache has finished populating.

If you're running a site with a service worker cache, its expected that you need at least one reload to pull the new content.

I understand. I'll pay more attention next time and see if "the next reload" gives me non-stale content.

You can also see this information in the application tab. It should tell you if you have a service worker pending activation, et cetera.

We could also switch the logic to online first instead of offline first

@jonahwilliams yep, I've been looking at that, but normally if I have that tab open, I'll just "clear storage" and be done with it. The issue is that normal visitors of a site are not expected to do that to get the latest.

I've read somewhere that the serviceworker itself is not cached by the serviceworker, and I haven't thoroughly tested my issue yet, so I'll pay more attention next time and get back to you :P