Renderelési módok és routeRules

7.1A négy mód

7.2routeRules — a teljes eszköztár

A nuxt.config.ts-ben glob-mintákkal rendelsz szabályt útvonalcsoportokhoz:

// nuxt.config.ts — egy tipikus SaaS felosztása
export default defineNuxtConfig({
  routeRules: {
    // ① marketing: build-időben statikus — a Worker meg sem hívódik
    '/':            { prerender: true },
    '/arak':        { prerender: true },
    '/blog/**':     { prerender: true },

    // ② publikus, megosztott nézet: ritkán változik, de nem build-time adat
    '/p/**':        { swr: 300 },

    // ③ az alkalmazás: mindig friss, és SENKI ne cache-elje
    '/app/**':      { ssr: true, headers: { 'cache-control': 'private, no-store' } },

    // ④ admin: nincs SEO-igény → nincs SSR-költség sem
    '/admin/**':    { ssr: false },

    // ⑤ API
    '/api/**':      { cors: true, headers: { 'cache-control': 'no-store' } },

    // ⑥ régi URL-ek életben tartása
    '/pricing':     { redirect: { to: '/arak', statusCode: 301 } },
  },
})

7.3Az isr és az swr — mit ígér a doksi, és mi történik Workers-en

A Nuxt dokumentációja az ISR/SWR route rule-oknál kifejezetten Vercelt és Netlifyt említi: ott ezek a szabályok platform-natív képességre fordulnak le — a szolgáltató saját CDN-je végzi a tárolást és a háttérben történő frissítést.

Cloudflare-en nincs ilyen natív leképezés. Ott ezek a szabályok a Nitro saját cache-rétegére fordulnak, ami az unstorage storage-rendszerét használja. És itt van a lényeg:

A megoldás: tedd a cache-t KV-be

// nuxt.config.ts
export default defineNuxtConfig({
  nitro: {
    preset: 'cloudflare_module',

    storage: {
      // a „cache" mountpontot használja a Nitro cache-rétege (swr/isr/cachedEventHandler)
      cache: {
        driver:  'cloudflare-kv-binding',
        binding: 'CACHE',          // a wrangler.jsonc-ben deklarált binding neve
      },
    },

    // fejlesztés közben maradjon fájlrendszer — gyorsabb és láthatóbb
    devStorage: {
      cache: { driver: 'fs', base: '.nitro/cache' },
    },
  },
})

// wrangler.jsonc
{
  "kv_namespaces": [
    { "binding": "CACHE", "id": "…" }
  ]
}

Ezzel a cache tartós és globálisan elérhető lesz. Cserébe a KV tulajdonságait örökölöd, és ezeket ismerni kell:

A kontrollálhatóbb út: cache a végponton, nem az útvonalon

Sok esetben jobb a routeRules helyett közvetlenül a drága API-végpontot cache-elni — mert ott te írod a kulcsot:

// server/api/public/report/[slug].get.ts
export default defineCachedEventHandler(async (event) => {
  const tenant = event.context.tenant
  const slug   = getRouterParam(event, 'slug')!
  return await buildPublicReport(event, tenant.id, slug)
}, {
  maxAge:      300,     // 5 percig friss
  staleMaxAge: 3600,    // utána még egy óráig kiszolgálható, közben frissül
  swr:         true,

  // ← EZ a lényeg: a kulcsot te írod, és benne van a tenant
  getKey: (event) =>
    `report:${event.context.tenant.id}:${getRouterParam(event, 'slug')}`,
})

Ugyanez függvényszinten is megy (defineCachedFunction), ha nem egy egész végpontot, hanem egy drága részszámítást akarsz cache-elni.

7.4Prerender a gyakorlatban

export default defineNuxtConfig({
  nitro: {
    prerender: {
      crawlLinks: true,                 // követi a talált <NuxtLink>-eket
      routes: ['/', '/arak', '/sitemap.xml'],
      failOnError: true,                // a build bukjon el, ne csendben hiányozzon egy oldal
    },
  },
})

Amit érdemes tudni:

• A prerender build-időben fut, tehát a benne lekért adat a build pillanatában érvényes. Blogbejegyzésnél ez rendben van (új bejegyzés → új deploy). Árazásnál, ami adatbázisból jön, már nem feltétlenül.
• A crawlLinks kényelmes, de kiszámíthatatlan. Ha egy link elgépelés miatt eltűnik, az oldal csendben kimarad. Kritikus oldalakat sorolj fel explicit módon is.
• Sok oldalnál lassul a build. Néhány száz oldal még kényelmes; több ezernél már érdemes inkább swr-t választani.
• Multitenant tartalmat ne prerenderelj, hacsak nem tudod build-időben az összes tenantot — és akkor sem, ha bármelyikük tartalma változhat deploy nélkül.

7.5ssr: false szigetek

Az ssr: false egy útvonalcsoportra azt jelenti: a Worker egy üres vázat ad vissza, a tartalom a böngészőben áll össze. Nem visszalépés, hanem tudatos csere.

A tipikus jó jelöltek: /admin/**, belső riportnézetek, összetett szerkesztőfelületek, bármi, ami bejelentkezés mögött van és nagy kliensoldali interaktivitást igényel. Ha az egész appod ilyen, akkor érdemes visszaolvasni az 1. modul „mikor ne Nuxt” szakaszát — nem baj, ha a válasz az, hogy mégis Nuxt, de tudatosan.

7.6Streaming SSR (4.5, kísérleti)

A 4.5 kísérleti SSR-streaminget hozott: a szerver nem várja meg a teljes HTML elkészültét, hanem darabokban küldi. Az elvi haszon a jobb TTFB — a böngésző hamarabb kap fejlécet és fejrészt, hamarabb kezdi tölteni a CSS-t.

Workers-en ez elvileg jó illeszkedés, mert a runtime natívan streamel (a Cloudflare best practices kifejezetten javasolja a stream alapú válaszokat a memóriahasználat miatt). Három dolgot viszont mérlegelj, mielőtt bekapcsolod:

• Kísérleti. Az API és a viselkedés változhat.
• A CPU-idő nem csökken tőle — ugyanannyi munkát végzel, csak korábban kezded küldeni.
• A cache-elés bonyolultabb lesz, mert a válasz nem egyben áll elő. Ha cache-elt oldalról van szó, a streamingnek nincs is haszna.

7.7Döntési térkép a te SaaS-odra

7.8Ellenőrizd magad