All SSR cache policy is one hardcoded header in setCacheControl (src/utils/url.ts): 5 minutes fresh, then stale-while-revalidate. Content publishes don't purge anything — a Tina save is only visible when the TTL runs out.
The result is the worst of both: low-traffic sites age out of cache between visits, so most real visitors wait for full server renders (measured 0.5–7 s per server island, and 6–10 s whole-page SSR on a cold site), while editors still wait up to 5 minutes to see their changes.
Proposed fix (PR to follow):
- Make the CDN TTL and stale-while-revalidate values configurable per site via env vars, defaulting to today's values so nothing changes without opt-in.
- Add a
Netlify-Cache-Tag to cached responses and call purgeCache (already available in our @netlify/functions version) when TinaCMS saves or deletes content, so a publish is visible in seconds regardless of TTL.
With purge-on-publish in place, a site can safely run a long TTL and serve nearly every visitor from the edge (~25 ms) instead of re-rendering.
All SSR cache policy is one hardcoded header in
setCacheControl(src/utils/url.ts): 5 minutes fresh, then stale-while-revalidate. Content publishes don't purge anything — a Tina save is only visible when the TTL runs out.The result is the worst of both: low-traffic sites age out of cache between visits, so most real visitors wait for full server renders (measured 0.5–7 s per server island, and 6–10 s whole-page SSR on a cold site), while editors still wait up to 5 minutes to see their changes.
Proposed fix (PR to follow):
Netlify-Cache-Tagto cached responses and callpurgeCache(already available in our@netlify/functionsversion) when TinaCMS saves or deletes content, so a publish is visible in seconds regardless of TTL.With purge-on-publish in place, a site can safely run a long TTL and serve nearly every visitor from the edge (~25 ms) instead of re-rendering.