How to reduce ISR costs after deployments?
Unanswered
tlmader (Patina Project) posted this in #help-forum
We have over a million content pages using ISR. Every code deployment invalidates the entire cache, which drives up our costs significantly.
We're currently prototyping a deployment to Vinext/Cloudflare, which gives us more control over this layer. But we'd prefer to stay on Vercel if there's a way to manage ISR costs or control when the cache gets invalidated.
Is there an option we're missing?
We're currently prototyping a deployment to Vinext/Cloudflare, which gives us more control over this layer. But we'd prefer to stay on Vercel if there's a way to manage ISR costs or control when the cache gets invalidated.
Is there an option we're missing?
7 Replies
@tlmader (Patina Project) We have over a million content pages using ISR. Every code deployment invalidates the entire cache, which drives up our costs significantly.
We're currently prototyping a deployment to Vinext/Cloudflare, which gives us more control over this layer. But we'd prefer to stay on Vercel if there's a way to manage ISR costs or control when the cache gets invalidated.
Is there an option we're missing?
I have no idea how you are revalidating the entire cache, but I would advise you to read the Next.js documentation, especially for the latest version.
You have several caching strategies. One of the earlier approaches was ISR (Incremental Static Regeneration), but that requires turning the entire page into a static shell. This has the direct consequence of removing any dynamic parts, such as user widgets or search parameters, from the page.
In the latest versions, you have Cache Components, where you can divide the static shell into smaller static portions. These portions can be revalidated when their dynamic data changes, either on demand or at specific time intervals. Uncacheable parts can also be isolated and excluded from the shell, allowing you to mix static content with dynamic content on the same page.
In earlier implementations, you could use revalidatePath or revalidateTag to update static content. These are still available. revalidatePath will revalidate the shell page and all its components, while revalidateTag can be used to revalidate individual components or specific cached data. Cache Components mean if you want you can only rerender what you change nothing else.
You have several caching strategies. One of the earlier approaches was ISR (Incremental Static Regeneration), but that requires turning the entire page into a static shell. This has the direct consequence of removing any dynamic parts, such as user widgets or search parameters, from the page.
In the latest versions, you have Cache Components, where you can divide the static shell into smaller static portions. These portions can be revalidated when their dynamic data changes, either on demand or at specific time intervals. Uncacheable parts can also be isolated and excluded from the shell, allowing you to mix static content with dynamic content on the same page.
In earlier implementations, you could use revalidatePath or revalidateTag to update static content. These are still available. revalidatePath will revalidate the shell page and all its components, while revalidateTag can be used to revalidate individual components or specific cached data. Cache Components mean if you want you can only rerender what you change nothing else.
@Nuitari I have no idea how you are revalidating the entire cache, but I would advise you to read the Next.js documentation, especially for the latest version.
You have several caching strategies. One of the earlier approaches was ISR (Incremental Static Regeneration), but that requires turning the entire page into a static shell. This has the direct consequence of removing any dynamic parts, such as user widgets or search parameters, from the page.
In the latest versions, you have Cache Components, where you can divide the static shell into smaller static portions. These portions can be revalidated when their dynamic data changes, either on demand or at specific time intervals. Uncacheable parts can also be isolated and excluded from the shell, allowing you to mix static content with dynamic content on the same page.
In earlier implementations, you could use revalidatePath or revalidateTag to update static content. These are still available. revalidatePath will revalidate the shell page and all its components, while revalidateTag can be used to revalidate individual components or specific cached data. Cache Components mean if you want you can only rerender what you change nothing else.
I've spent time reviewing the Vercel docs, and I can't find a clear answer about how code deployments impact ISR or the CDN cache. The closest I found was the Edge Network caching doc, which states "the cache is automatically purged upon a new deployment being created." But it's unclear if this applies to ISR specifically, or just the edge cache. Maybe you can point me in the right direction?
We deploy small changes frequently, and not all of these changes impact all cached pages. Yet our ISR writes consistently spike each time we deploy. Does this change your advice about Cache Components? I'm looking into the pattern, but I'm unsure it actually addresses this issue.
We deploy small changes frequently, and not all of these changes impact all cached pages. Yet our ISR writes consistently spike each time we deploy. Does this change your advice about Cache Components? I'm looking into the pattern, but I'm unsure it actually addresses this issue.
i think in like 20 min
Sure thing
The best thing I can cite is this comment from leerob in 2022: https://github.com/vercel/vercel/discussions/7765#discussioncomment-2710450
Every deployment has a unique key used for caching based on the deployment url created at build time. This means that users will never see content from a previous deployment and there's normally no need to invalidate it.But the docs have been restructured since then and clarification has been lost.
Saint Hubert Jura Hound
This is one of those times where it might just be easier to search through the source code n see what happens. Im sure a lot changed between 2022 and now