ISR & SWR With routeRules

ISR and SWR options tell Nitro to cache rendered HTML and serve stale content while regenerating in the background.

4 min read Level 3/5 #nuxt#isr#swr

What you'll learn

Use isr or swr in routeRules with a TTL
Compare ISR vs SWR semantics
Pair with deploy targets that honor cache directives

ISR (Incremental Static Regeneration) and SWR (Stale-While-Revalidate) are how you get the speed of static rendering with the freshness of SSR. Both rely on a cache plus a background refresh.

SWR

// nuxt.config.ts
export default defineNuxtConfig({
  routeRules: {
    '/blog/**': { swr: 3600 } // cache for 1h, refresh in background
  }
})

How it works:

First request — render fresh, cache the HTML.
Within TTL — serve cached HTML (fast).
After TTL — serve stale HTML immediately, kick off a re-render, populate cache for next time.

The user never waits for regeneration after the first hit.

ISR

routeRules: {
  '/products/**': { isr: 3600 }, // numeric TTL
  '/marketing/**': { isr: true } // cache indefinitely until manually invalidated
}

ISR is similar but designed for edge platforms (Vercel, Netlify) that distribute the cache across regions. On supported deploys, ISR caches at the edge nearest each visitor.

SWR vs ISR

SWR — typically scoped to the Nitro server’s local cache. Works anywhere Nitro runs.
ISR — edge-distributed cache, requires platform support. Best on Vercel/Netlify/Cloudflare.

If you are unsure which to use and deploy on a modern platform, isr is usually the right pick.

When to Reach For It

Blog posts that change a few times a day.
Product listings updated hourly.
Any page where serving slightly stale content beats slow re-rendering.

Do not use SWR/ISR for highly personalized pages — the cache key is the URL, so all users share the same HTML.

SPA Mode →