SWR or ISR for Periodically Updated Nuxt 3 Routes?

Direct answer

For a high-traffic Nuxt 3 route updated hourly, use swr: true in routeRules when your deployment runs on a Nitro-compatible edge platform. SWR returns cached HTML immediately and revalidates in the background, so traffic bursts after expiry do not wait on a single regeneration. ISR can delay the first request after TTL expiry while the page rebuilds, which creates latency spikes and may present slow responses to SEO crawlers.

Confirmed facts and likely explanation

Nuxt 3.8+ exposes experimental swr with a default TTL of 3600 seconds and isr requiring an explicit ttl. Both depend on a Nitro-compatible edge platform; self-hosted Node.js deployments may fall back to per-request SSR and lose CDN benefits. Client-side useFetch or useAsyncData navigation does not automatically inherit routeRules and may bypass the CDN cache.

The likely explanation for the origin-load difference is that SWR decouples serving from revalidation. Whether ISR regeneration after TTL expiry is blocking or background is provider-dependent and should be treated as unverified until measured on your target platform.

Steps for this case

1. Add the route rule to nuxt.config.ts:

export default defineNuxtConfig({
  routeRules: {
    '/blog/[slug]': { swr: true }
  }
})

1. Confirm your deployment target. Vercel, Netlify, Cloudflare, and similar Nitro edge providers are the expected environments. If you self-host on plain Node.js, assume swr and isr may not apply and use origin-controlled caching instead.
2. Keep swr or isr off authenticated routes unless you implement a custom cache key that includes session identity. URL-only rules can serve one visitor's cached HTML to another.
3. Configure API-level caching separately for client-side data fetching; page-level routeRules do not automatically cache useFetch payloads after hydration.

Verification

• Request the deployed route and inspect Cache-Control and provider-specific cache headers in the browser network tab.
• Wait past the TTL, refresh once, and compare response times. An immediate response is consistent with SWR; a delayed first response followed by fast responses is consistent with ISR regeneration on expiry.
• Open an authenticated variant of the route in a private window to confirm cached HTML is not shared across sessions.

Missing diagnostic detail

What is your deployment target? If you are self-hosting on Node.js without an edge cache, neither SWR nor ISR may behave as described, and the recommendation changes to server-side cache headers or API-level invalidation.

Assumptions and uncertainty

This guidance assumes Nuxt 3.8 or later and a Nitro provider that implements edge caching. Background revalidation for SWR and blocking versus background regeneration for ISR are not guaranteed across providers. Mark these for review after you measure header behavior on your production target.