Cache busting strategy documented
Why it matters
Without documented cache-busting strategy, every developer on the team is guessing: does the CDN auto-purge on deploy? Do users need to hard-refresh to get the latest build? Are the service worker caches versioned? ISO 25010:2011 time-behaviour requires that the system delivers correct and current assets; gaps in cache-busting understanding lead to incidents where users receive stale JavaScript after a critical bug fix, because no one was certain which caching layer was holding the old version.
Severity rationale
Info because undocumented caching is a knowledge-management gap rather than an active bug — the system may function correctly, but the absence of documentation increases incident response time when stale-asset problems do occur.
Remediation
Document your caching stack in docs/caching-strategy.md or the project README. Cover three layers: asset filename hashing, HTTP cache headers, and service worker versioning.
<!-- docs/caching-strategy.md -->
## Cache Busting Strategy
### 1. Asset Hashing
All JS/CSS assets in `.next/static/` are named with content hashes (e.g., `main-abc123.js`).
Filenames change only when file content changes.
### 2. HTTP Headers
- Hashed assets: `Cache-Control: public, immutable, max-age=31536000`
- HTML: `Cache-Control: public, no-cache`
### 3. Service Worker
Cache name includes app version (`app-cache-v2.1.0`).
Old caches are deleted in the `activate` event.
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