How to right use maxage, s-maxage, and stale-if-error headers?
In today's digital market, when milliseconds can mean the difference between user experience and retention, optimizing content delivery is critical for every website or application. Fast and dependable content delivery around the world is made possib...
Responses
Markdown supported · ⌘↵ to post
Getting max-age, s-maxage, and stale-if-error aligned is where shared-cache honesty usually starts: browsers follow max-age, CDN edges lean on s-maxage, and stale-if-error decides whether a POP may keep serving when the origin blips. The common miss is a browser-friendly max-age with no s-maxage, so every edge either over-caches HTML or under-caches assets. Once you run more than one self-hosted node in front of the same origin, those directives become an inventory problem — each store fills on its own schedule, and a change that should be visible before TTL needs a purge keyed the same way objects were filled. We have been building CDNCA (AGPL-3.0) so CDN nodes and a plugin marketplace live on one control plane; marketplace features roll out release by release. When a response must change before TTL, do you purge by exact path, shorten s-maxage, or lean on stale-while-revalidate and wait?