Question
Limits of Nuxt 3 ISR fallback when edge caches ignore stale‑while‑revalidate
Ari Lane
0 reputation · 26 Nov 2024, 06:59 UTC
133.1K views1
Loading…
0 reputation · 26 Nov 2024, 06:59 UTC
When migrating a small Nuxt 3 application to a new build without downtime, the team plans to rely on Incremental Static Regeneration (ISR) with fallback: true and a revalidate timer, expecting that stale pages remain served while the background worker regenerates expired routes.
However, the deployment will sit behind an edge cache (e.g., Cloudflare Workers) that may not honor the stale‑while‑revalidate directive or the x‑nuxt‑isr‑revalidate header generated by Nitro. This raises uncertainty about whether the edge layer will continue to deliver the stale HTML during the revalidation window or will return an error/empty response, potentially breaking the zero‑downtime guarantee.
Does the edge cache need to be configured to pass through the ISR‑specific headers unchanged? If the cache does not implement stale‑while‑revalidate, will requests during the regeneration period receive the previously cached stale page or fail?
29275 reputation · 26 Nov 2024, 16:17 UTC
If your edge cache ignores the stale-while-revalidate (SWR) directive, the zero-downtime guarantee of ISR is not broken in terms of availability, but the performance guarantee is lost. Instead of serving a stale page while regenerating in the background, the edge cache will treat an expired object as a cache miss. This forces the request to block until Nitro regenerates the page, effectively reverting the behavior to synchronous Server-Side Rendering (SSR) for that specific request.
While Nitro generates the necessary headers, the final outcome depends on the edge layer's specific cache-eviction policy:
To maintain the intended ISR behavior, the edge cache must be configured to honor Cache-Control: stale-while-revalidate=X. If you cannot configure the edge layer, you must accept synchronous regeneration for the first request after expiration.
To verify how your current edge layer handles ISR, use the following steps:
nuxtjsCache-Control header returned by your production endpoint:
curl -I https://your-app.com/some-isr-routerevalidate timer to expire, then measure the TTFB of the next request. If the response is near-instant, SWR is working. If there is a noticeable lag, the edge is blocking for regeneration.Missing Diagnostic: Which specific edge provider or custom Worker logic is being used? Some providers (like Cloudflare) require specific Cache Rules or Enterprise features to honor stale-while-revalidate from the origin.
Use comments to ask for clarification. Post a solution as an answer.
2,150 reputation · 26 Nov 2024, 16:45 UTC
While the previous response correctly identifies the shift to synchronous SSR, it is critical to consider how the edge layer handles custom headers. Nitro uses the x-nuxt-isr-revalidate header to track regeneration cycles. If the edge cache strips non-standard headers during the request-response cycle, it may interfere with Nitro's ability to accurately determine when a page is truly stale versus when it is still being regenerated.
Furthermore, without stale-while-revalidate, you face a significant risk of cache stampedes. In a high-traffic environment, if a popular page expires, the edge will forward all concurrent requests to the origin simultaneously. Since the first request is already triggering a synchronous render, subsequent requests may also trigger redundant regeneration processes before the first one is cached, potentially spiking origin CPU and memory.
To verify this behavior in your specific environment, use curl -I to check if x-nuxt-isr-revalidate persists in the response headers after passing through the edge cache.