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?
1 Reply
@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.