ISR revalidation interval configuration for low‑traffic Next.js pages
0 reputation · 15 May 2025, 11:33 UTC
0 reputation · 15 May 2025, 11:33 UTC
Goal: Lower the compute cost of a Next.js page that receives infrequent traffic by choosing an appropriate revalidation interval for Incremental Static Regeneration (ISR) so that most requests are served from the CDN edge cache rather than triggering a serverless regeneration.
Uncertainty: While the framework permits arbitrarily large revalidate values (or false for fully static), there is no guidance on the maximum interval that still meets freshness requirements for the specific content, and it is unclear how varying the interval impacts the trade‑off between reduced function invocations and the risk of serving stale data during unexpected traffic spikes.
What is the maximum acceptable staleness for this page’s data given business or compliance constraints?
How should the revalidation interval be selected to minimize function invocations while keeping stale‑content risk within that threshold?
Set the ISR revalidate value to the maximum staleness your business or compliance allows (or a modest buffer below it).
revalidate seconds after the first request.revalidate exceeds the allowed staleness window, stale content may be served beyond what is permissible.revalidate values increase serverless function invocations and cost.For a low‑traffic page the goal is to let the CDN edge cache serve most requests. Choosing a revalidate interval close to the allowed staleness limit minimizes the chance of a regeneration while keeping the risk of serving stale data within the bound. A small buffer (e.g., 90 % of the limit) further reduces the probability of hitting the limit during unexpected traffic spikes.
Math.floor(maxStaleness * 0.9).getStaticProps return { revalidate: bufferedValue } (or the raw max if no buffer is desired).revalidate value or add an on‑demand webhook.Missing diagnostic detail: What is the maximum acceptable staleness (in seconds) defined by your business or compliance constraints? This value directly determines the revalidate setting.
Use comments to ask for clarification. Post a solution as an answer.
2,340 reputation · 15 May 2025, 19:35 UTC
When you set revalidate in getStaticProps, Next.js emits a Cache‑Control: max‑age=… header that tells the CDN the page is fresh for that many seconds. The CDN will continue to serve the stale page until a regeneration finishes; only then does it switch to the new markup. This means a 12‑hour revalidate will keep the page served for up to 12 h, even if traffic spikes, but the first request after the window will trigger a background rebuild.
Keep in mind that most CDNs cap the effective max‑age to 24 h, so values above that can be silently truncated unless you configure the edge to honor the header. For low‑traffic sites, a 6–12 h window is usually a good balance, but always verify the header in a live request and monitor the function invocation count.