i had a client clearing her cache for three weeks and it was a service worker

three weeks. that is how long i had her clearing browser cache google chrome, then trying edge, then trying her phone, while a stale homepage kept coming back on the one machine that mattered, and that was of course the machine she used to show the site to customers.

the site had a pwa plugin on it from a previous agency. long dead as far as anyone knew, deactivated, gone from the plugin list. the service worker it registered was still sitting in her browser serving the old app shell out of its own cache, and a service worker does not care that the plugin is gone. it will serve a copy of your homepage from last year quite happily until something unregisters it.

here is the bit that cost me the three weeks. the tick box for cached images and files does not touch four separate things: 1. a registered service worker and the caches it owns, 2. the dns entries and open sockets chrome is holding for that host, 3. the copy sitting at the cdn edge, 4. whatever her office proxy decided to keep. clear site data, under the application tab in devtools, is the one that gets the service worker, and nobody in a support email is ever going to find that on their own.

the fix came in two parts. i registered a tiny service worker that calls skipWaiting, deletes every cache it can enumerate and then unregisters itself, so the next visit from any affected browser cleans itself up without anyone being talked through a menu. then a clear-site-data header on one url as belt and braces for the people who do not come back for a month.

the lesson i took out of it is that when someone says the cache is stale, the question is not how do i get them to clear it. the question is which copy is stale and who owns that copy, because in this case it was owned by a script the client did not know existed and could not have cleared if she had tried.