Limits of Nuxt 3 ISR fallback when edge caches ignore stale‑while‑revalidate

Question

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?

Tasadduq Burney · Answer

The Impact of SWR Ignorance on ISR Fallback
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.

Likely Behavior vs. Confirmed Facts
While Nitro generates the necessary headers, the final outcome depends on the edge layer's specific cache-eviction policy:

Confirmed: Without SWR support, the "background" nature of ISR is disabled. The first user to hit an expired route will experience a significant increase in Time to First Byte (TTFB) because the server must generate the HTML before the edge can cache and serve it.
Likely: If the edge cache strictly follows a TTL (Time-To-Live) and does not support SWR, it will not return an error or empty response (unless the origin server fails), but it will stop serving the stale version immediately upon expiration.
Risk: In high-traffic scenarios, ignoring SWR can lead to a "cache stampede," where multiple concurrent requests for the same expired page trigger multiple simultaneous regeneration processes on the origin server.

Required Configuration and Verification
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:

Inspect Headers: Run a curl command to check the Cache-Control header returned by your production endpoint:
curl -I https://your-app.com/some-isr-route

Test Expiration: Wait for the revalidate 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.
Monitor Origin: Check Nitro server logs during a revalidation window to see if regeneration is triggered asynchronously or if it blocks the response stream.

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.

Limits of Nuxt 3 ISR fallback when edge caches ignore stale‑while‑revalidate

1 answer

0 question comments

The Impact of SWR Ignorance on ISR Fallback

Likely Behavior vs. Confirmed Facts

Required Configuration and Verification

Your perspective belongs here.