ISR revalidate=0 boundary in Next.js 12 reverting static generation to server rendering

Rendering Behavior of revalidate=0

In Next.js 12, setting revalidate = 0 within getStaticProps effectively disables Incremental Static Regeneration (ISR) for that route. This configuration forces the server to execute getStaticProps on every request, shifting the page's behavior from static generation to a pattern that mimics Server-Side Rendering (SSR). While the page is still technically defined via static props, the lack of a cache window means it cannot be served as a static asset from the filesystem or edge cache.

CDN and Header Interactions

The relationship between Next.js ISR and CDN behavior depends on how the edge cache interprets the Cache-Control headers generated by the framework. When revalidate is transitioned or removed, the following behaviors typically occur:

CDN Persistence of s-maxage

CDNs do not inherently "know" when a Next.js route configuration changes; they only react to the headers sent in the HTTP response. If revalidate is removed or set to 0, Next.js will stop sending the s-maxage header associated with the previous ISR window. However, the CDN may continue to serve the prior cached version of the page until that specific s-maxage timer expires. To force an immediate update, a manual CDN cache purge is required.

Mixed-Route Prioritization

Next.js 12 does not support global ISR configurations. Caching is handled on a per-route basis. If a site has mixed configurations:

• Per-route revalidate: Takes absolute priority. The framework generates specific s-maxage and stale-while-revalidate headers for that request.
• Global CDN Defaults: If a route has no ISR configuration (or revalidate=0), the CDN falls back to its own default caching policies or the Cache-Control: no-cache headers sent by the server.

Header Transition during Upgrades

When transitioning from a non-zero value to 0, the expected behavior is a shift from Cache-Control: s-maxage=X, stale-while-revalidate=Y to a header that instructs the browser and edge to not cache the content (typically Cache-Control: private, no-cache, no-store, max-age=0, must-revalidate). This ensures that the "server-rendered" nature of the revalidate=0 setting is respected by the network layer.

Verification Steps

To verify if a route has successfully reverted to server rendering and is bypassing the cache, use the following methods:

• Inspect Headers: Check the X-Nextjs-Cache header. A value of MISS on every refresh indicates the page is being regenerated on the server.
• Server Logs: Monitor server-side logs to confirm that getStaticProps is executing on every single request rather than at the defined interval.
• Network Timing: Compare the Time to First Byte (TTFB) against a known static page; revalidate=0 will show higher latency due to the required server execution.

Diagnostic Note: To provide a more specific recommendation on header drift, please specify if you are using a Vercel deployment or a custom CDN (e.g., Cloudflare, Akamai), as edge-side overrides can mask Next.js header changes.