Service worker cache versioned and cleaned on deploy
Why it matters
A service worker that caches resources without versioning accumulates stale content indefinitely. When you ship a bug fix or critical update, users with a running service worker continue receiving the broken cached version — potentially for weeks, until they manually clear their cache or the browser evicts it. The cache name must change on each deploy, and the activate event must delete old caches. ISO 25010:2011 time-behaviour flags cache effectiveness; the operational risk is users being stuck on outdated or broken application versions with no server-side way to force an update.
Severity rationale
High because unversioned service worker caches leave users running stale application code after deploys, with no server-side mechanism to force a refresh without manual cache clearing.
Remediation
Include a version string or content hash in every cache name and delete all prior cache versions in the service worker's activate event.
// public/service-worker.js
const CACHE_NAME = 'app-cache-v2.1.0' // bump on each deploy
self.addEventListener('activate', (event) => {
event.waitUntil(
caches.keys().then((keys) =>
Promise.all(
keys.filter((key) => key !== CACHE_NAME).map((key) => caches.delete(key))
)
)
)
})
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Performance Deep Dive Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- iso-25010:2011 · time-behaviour — Time Behaviour (performance efficiency)
Taxons
History
- 2026-04-18·v1.0.0·Initial import from performance-deep-dive·automated