Great, it was implemented recently?
When I started using partial build and lambda function for SSR I think I tested it and the page that had been SSRendered continued to deliver the old version.
I was using following Cache-Control:
public, max-age=60, s-maxage=2592000
The expectation is that after a new deploy the page URL hits the lambda function again, would that happen?
Not using any proxy…
It was implemented very near from the start of Netlify, so it’s not a new feature.
If you are using that cache-control header, then your SSR page will be cached likely for 30 days since s-maxage overrides max-age for proxy caches. That’s likely why you are seeing the old version.
Yup, it works, my point is about:
I mean, I was expecting to cache SSR output for up to 30 days or until a new deployment is triggered, and I think it’s not working, just tested again 
Sorry this thread has been so long in waiting!
Whose cache are you talking about here?
In your visitor’s browser cache, you’ll have no control over when it is re-fetched, after it receives the asset with the cache-control header.
In our CDN’s edge cache, we aim to respect the header as well so I believe a redeploy will not change the fact that the cache was given a long timeout (or, said another way, our nodes will respect the cache like browsers).
when something is NOT cached in the proxy - which is a per-CDN-node cache, and we have dozens of nodes including newly created ones with no cache - it will be fetched with the current header to the CDN node and cached according to the directive.
Our networking team has confirmed these assertions, so this should be your guiding light - if you need your function’s response to be easily/quickly removed from our CDN cache, you should not set long cache timeouts on that response. Perhaps a timeout of something more like 5 or 10 minutes would best serve your needs?
Hey @foot ,
Okay, I know your suggestion works, our current implementation is already setting only 10 min of maximum cache age, but it’s still not the best scenario.
I’m trying to deploy a JAMstack but with lot of views, so building entire site on each content change is not a good practice because it requires long time, then we’re building most important pages plus up to 300, the rest is SSRed, but as a JAMstack it doesn’t change until the content changes and a new deploy is triggered.
Currently we’re calling lambda functions much more than necessary because new deploys doesn’t purge cache, consequently I can’t set a long cache rule and the same slug is being SSRed many times unnecessarily as the content is not changed at all.
Additionally, without stale-while-revalidate and with a short cache rule, is common to take “long” time to access not pre-rendered views because they have to be SSRed again and again…
So, your suggestion works and it’s what we’ve been using for some time, but it uses unnecessary resources and at the same time results in slower server responses 
Hey @ecomplus ,
Cheers for your patience. We’ve got a feature filed internally for this and we’re working hard to bring the best solution to fruition. I can’t put timeframes on any of this, regrettably, but do take my word that it’s on our radar and we’re exploring our options.
@Scott any update on this? We experience the same thing… Wondering if this got implemented.
Hi @aj-circadence,
New to this thread - so haven’t read through everything yet, but does this look like something that might help you: On-demand Builders | Netlify Docs?
Hello,
I’ve been trying long and hard to use the stale-while-revalidate cache control extension with Netlify, and didn’t succeed, so I ended up in this thread. Adding support for stale-while-revalidate would be very appreciated, since it would allow developers to implement ISR by only using cache control headers (as a Remix.run user, this is my preferred way to go):
Cache-Control: public, max-age=1, s-maxage=1, stale-while-revalidate=31536000
(CDN always returns a stale response, which is very fast, and in the background fetches the fresh data for the following requests)
On demand builders wouldn’t work for my use case.
Thanks
On Demand Builders are the only way we’re providing anything close to stale-while-revalidate as of now. Any specific reason why it won’t work for you?