My company has a Vercel project, built on Gatsby which uses a Cloudflare CDN.
On July 29th, we had an issue where the JS files of my app would return a 404 after new deploys. I know that Vercel doesn’t recommend using a CDN, but I’m trying to understand why this seemed to be working before, and stopped around a month ago.
Seems like when the problem was happening, JS files coming from Vercel had a cache-control header with value public,max-age=31536000,immutable, which CF was caching. We solved the issue by adding a rule to CF for no 404s to be cached. Afterwards, seems like JS files come with header: public, max-age=0, must-revalidate, which means CF won’t cache any of them.
It seems like there was also a significant increase in our time to first byte which indicates that CF was correctly caching before, but is not anymore.
I wanted to know if there was a change in Vercel’s default header cache around July 29th. The fact that we’ve confirmed that files were temporarily getting the immutable header, but later changed to a must-revalidate header seems to indicate so, but we’re not sure about what was the value before that date, so that I can apply the same config, and get CF’s cache back to working.
I couldn’t find anything mentioning this change, except this community thread, that mentions a similar issue around the same time: Svelte cache 404 bug
Hello, Kelly. Let me share what I shared at a support ticket we have open:
The problem came up without any changes on our end, and we could confirm that at some point, .js files (including 404s) had a cache-control header with value:
cache-control: public,max-age=31536000,immutable
This can still be seeing, comparing a preview env still available from July 31st:
(We have not been getting any immutable values since at least August 9th. I just chose the August 21st date cause there was an unrelated a change to our vercel.json after that, and I didn’t want to raise suspicion that that change was what caused the different behavior).
The CDN doesn’t affect those preview environments, so I assume the change must have been on your end.
I hadn’t thought before of comparing the behavior with envs from before the incident. Based on this one, from July 23: https://marketing-site-dgypvk7x6-tremendous-front-end.vercel.app/ I couldn’t identify any differences in the behavior of requests from what is happening now. Which is weird, cause we were still getting some instability in the caching (since then, we’ve started using the asset prefix option in Gatsby, so JS resources are fetched directly from the Vercel domain, without going through the CDN)
Thanks for the details. From what I can tell, it appears that the middleware in the first deployment is explicitly setting cache-control: public,max-age=31536000,immutable, whereas in the second example deployment, the middleware is not setting cache-control at all, and the default is being used. Are you using middleware in your project?