From vercel docs: "Vercel does not allow bypassing the cache for static files by design.”
I’m trying to understand the reasoning behind this approach, especially since ISR generates updated content and changes the ETag upon revalidation. So why not just return 304 Not Modified and bypass the cache in this case? Would save a lot of data transfer.
Indeed on Chrome it seems like 304 Not Modified is returned and X-Vercel-Cache = BYPASS
But on Safari I never get the 304 Not Modified and the data is always grabbed from the cache
Vercel Alum
Hi, !
Vercel's caching strategy for static files is designed to prioritize performance by serving content from edge caches whenever possible. This approach doesn't allow bypassing the cache for static files by design.
I’m trying to understand the reasoning behind this approach, especially since ISR generates updated content and changes the ETag upon revalidation.
For Incremental Static Regeneration (ISR) pages, there's more of nuanced approach. ISR pages can generate updated content and change ETags upon revalidation, allowing for a balance between serving cached content quickly and making sure content is fresh.
Indeed on Chrome it seems like 304 Not Modified is returned and X-Vercel-Cache = BYPASS
But on Safari I never get the 304 Not Modified and the data is always grabbed from the cache
The behavior you've observed, where Chrome receives 304 Not Modified responses with an X-Vercel-Cache: BYPASS header, while Safari always fetches from the cache is an interesting discrepancy.
This difference suggests that while Vercel does support conditional requests and 304 responses for ISR pages (as seen in Chrome), there may be variations in how different browsers handle caching or send conditional requests. The consistent cache hits in Safari could be due to browser-specific caching strategies or potential inconsistencies in how Vercel's edge network interacts with different user agents.
This topic is closed. It no longer accepts new replies.
