SPAs invert the classic caching profile: nearly everything is immutable JavaScript and assets, except the one small HTML document that names them, and the seam between those two regimes is where SPA delivery succeeds or breaks. Most SPA outages that look like application bugs are seam mismanagement.
The two-regime model
Fingerprinted chunks (app.3f9c2.js) are the easy regime: content-addressed, immutable, cache-forever with the immutable directive, our validators article’s graduated citizens. The HTML shell is the hard regime: it must reflect the latest deploy promptly (it references the fingerprints) while still serving from edge cache for speed, short s-maxage with stale-while-revalidate, purged by tag on deploy, is the standard recipe. Everything interesting happens because these regimes reference each other across deploys.
The deploy-time race
Deploy N+1 ships new fingerprints; users holding shell N still request chunks N. If deploys delete old chunks, those users 404 mid-session, the classic post-deploy error spike that looks like a broken release and is actually a retention policy. The fix is boringly effective: retain previous chunk generations (several deploys’ worth, or time-based), deploy assets before the shell that references them, and treat chunk 404s in monitoring as a distinct, alarm-worthy signal, they are always a seam bug, never user error.
The prerendering convergence closes the loop with earlier articles: SPA shells increasingly arrive via edge-side rendering or static prerendering, HTML generated per route at build or at the edge, hydrated client-side, which moves the shell from smallest-cacheable-document to genuinely cacheable content with the composition techniques from our ESI article governing its dynamic islands. The two-regime model survives intact; the shell regime just gets richer and faster. What does not change is the seam discipline: fingerprints, retention, deploy ordering and drift detection remain the deliverability core of every SPA, however its HTML gets made, and they remain the checklist that separates deploys nobody notices from deploys everybody does.
Runtime seam management
Long-lived SPA sessions drift: a tab open for days holds ancient code requesting ancient endpoints. Mature apps version their API contracts, detect deploy drift (a version header on API responses, compared client-side), and prompt or force refresh at safe moments. Service workers add a third cache regime with its own update lifecycle, powerful, and infamous for serving zombie shells for months when misconfigured; if you deploy one, its update-and-activate policy is part of your delivery architecture, not a frontend detail.
In practice
Verify the regimes explicitly: chunks report immutable and never revalidate; the shell turns over within minutes of deploy (test it); previous-generation chunks remain fetchable across your retention window; and chunk-404 monitoring exists with an owner. Then rehearse the ugly case, deploy during peak with long-session users simulated, and watch the seam hold. SPA delivery is a solved problem exactly to the degree these checks are automated.
SPA delivery reviews here run the seam checklist and the peak-deploy rehearsal. Chunk-404 dashboards are a standard deliverable.