> Webáruház gyorsítótárazása Nuxtban: útvonalszabályok, Nitro- és CDN-kulcsok, ISR-korlátok, címkés törlés, és a vevői árak kizárása a közös gyorsítótárból.
>
> Web page: https://balazscsorba.com/hu/blog/nuxt-caching-isr-commerce · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/nuxt-caching-isr-commerce.md) · [Deutsch](https://balazscsorba.com/de/blog/nuxt-caching-isr-commerce.md)
> Author: Balázs Csorba · Published: 2026-10-05 · Keywords: nuxt route rules caching, nuxt isr, nitro cache swr, cache invalidation purge by cache tag, nuxt isr cloudflare, stale while revalidate commerce, headless commerce caching, vercel isr pricing, cdn cache key vary, personalized prices cached pages

[Blog](https://balazscsorba.com/hu/blog)/Webfejlesztés

# Headless webáruház frontendjének gyorsítótárazása Nuxtban: útvonalszabályok, ISR és törlés

Webáruház gyorsítótárazása Nuxtban: útvonalszabályok, Nitro- és CDN-kulcsok, ISR-korlátok, címkés törlés, és a vevői árak kizárása a közös gyorsítótárból.

[Balázs Csorba](https://balazscsorba.com/hu/about)·2026\. október 5.·11 perc olvasás

-   Nuxt
-   Caching
-   ISR
-   Headless commerce
-   Cache invalidation

![Egy oldal csúszik ki egymásra rakott cache-tálcákból, mellette egy óra.](https://balazscsorba.com/images/blog/nuxt-caching-isr-commerce/cover.webp?v=ac033b020d)

## A lényeg röviden

-   Az útvonalosztályonként válasszon gyorsítótár-módot, nem az egész oldalra: ami sosem változik, azt prerenderelje, a katalógusadatokhoz stale-while-revalidate való, a kosár, a pénztár és a fiók pedig nem kerül gyorsítótárba.
-   Az isr név nem jelent mindenhol edge-gyorsítótárazást; a Nuxt dokumentáció a CDN-részt a támogató platformokra korlátozza, jelenleg a Netlifyra és a Vercelre, ezért ellenőrizze a ténylegesen kapott fejléceket.
-   A Nitro a kiszolgálói rétegen nem tud címkék szerint törölni. Címkézze a válaszokat íráskor, törölje címke szerint a CDN-en aláírt webhookról, a rövid max-age pedig legyen a tartalék.
-   A vevőspecifikus oldal vázát gyorsítótárazza, az árat pedig nem gyorsítótárazott, privát végpontról kérje le. A vevői adat soha ne jusson megosztott gyorsítótárba, és ezt két fiókkal teszteljük.
-   A találati arányt minden réteg válaszfejlécéből mérje, és kövesse a legrégebbi gyorsítótáras bejegyzés korát, mert az az elavulási keret, amelyet senki nem ellenőriz, nem keret.

Ezen az oldalon

1.  [Melyik gyorsítótár-mód illik az egyes útvonalosztályokhoz?](https://balazscsorba.com/#which-mode-per-route-class)
2.  [Mit csinálnak valójában a Nuxt útvonalszabályai?](https://balazscsorba.com/#nuxt-route-rules-what-each-mode-does)
3.  [Hogyan gyorsítótárazza a Nitro a választ?](https://balazscsorba.com/#how-nitro-caches-on-node-and-at-the-edge)
4.  [Hogyan jutnak el a katalógusváltozások a gyorsítótárba?](https://balazscsorba.com/#invalidating-on-catalog-change)
5.  [Hogyan gyorsítótárazhatók a vevői árakat mutató oldalak?](https://balazscsorba.com/#personalized-b2b-prices-with-cached-pages)
6.  [Hol nem érdemes a stale-while-revalidate-et használni?](https://balazscsorba.com/#stale-while-revalidate-trade-offs)
7.  [Hogyan mérjük a találatokat, és mi szokott elromlani?](https://balazscsorba.com/#measuring-hit-ratio-and-footguns)
8.  [Bevezetési ellenőrzőlista](https://balazscsorba.com/#checklist-and-rollout)
9.  [Források](https://balazscsorba.com/#sources)

Cikk meghallgatása

0:000:00

**A headless webáruház frontendjének gyorsítótárazása Nuxtban** elsősorban azon múlik, mely oldalak oszthatók meg. A katalógusoldalak, a kategórialisták és a marketingoldalak percekig, órákig vagy a következő telepítésig tárolhatók az edge-en, mert minden látogató ugyanazt a bájtsort látja. Egy bejelentkezett B2B vevő termékoldalát viszont nem lehet így kezelni, mert az ár, a rendelhető mennyiség és a kosárba helyezés állapota attól függ, ki kérdez. A mechanika nem bonyolult. A hibák abból erednek, hogy minden útvonalra ugyanazt a gyorsítótár-módot alkalmazzák.

A működő szabály rövid: útvonalosztályonként válasszon módot, a személyre szabott adatot tartsa távol minden megosztott tárolótól, döntse el előre, mennyire lehet elavult az egyes osztályok tartalma, és határozza meg, hogyan jut el a katalógusváltozás a gyorsítótárig. A Nuxt útvonalszabályai útvonalanként adják meg a módot. A Nitro dönti el, hogyan gyorsítótárazza a szerver a választ. A CDN dönti el, mi osztott, és hogyan működnek a törlések. Mindegyik rétegnek saját alapértelmezése, saját fejlécszókincse és saját korlátai vannak, és 2026 októberében ezek eltérnek a Vercel, a Cloudflare és a sima Node-szerver között. Az alábbi szakaszok ezeken a rétegeken haladnak végig, majd a törlési útvonalakon, a személyre szabás határán és a mérésen.

## Melyik gyorsítótár-mód illik az egyes útvonalosztályokhoz?

Prerenderelje, ami sosem változik, a stale-while-revalidate-et használja a rövid késést tűrő katalógusadatokhoz, a kosarat, a pénztárat és a fiókot pedig tartsa nem gyorsítótárazva és szerveroldalon renderelve. A táblázat kiindulópont. Az elavulási keretek üzleti döntések, amelyeket osztályonként érdemes egyeztetni, nem keretrendszer-alapértelmezések.

Útvonalosztály

Mód

Hol gyorsítótárazzuk

Elavulási keret

Személyre szabás

Érvénytelenítési eszköz

Marketing- és jogi oldalak

prerender

build-kimenet, CDN

a következő telepítésig

nincs

újratelepítés

Kategórialisták

swr vagy isr

szerver és CDN

osztályonként egyeztetve

nincs

címkés törlés katalógusváltozáskor

Termékoldal váza

swr, kliens oldali ár

csak a HTML-váz

osztályonként egyeztetve

nincs a HTML-ben

címkés törlés plusz max-age

Vevői árak és készlet

kliens sziget, nem gyorsítótárazott API

sehol nem osztott

nincs, kérésenként olvassuk

vevőnként

nem alkalmazható

Kosár, pénztár, fiók

ssr, no-store

sehol nem osztott

nincs

vevőnként

nem alkalmazható

A vevőspecifikus adatok útvonala egyáltalán nem gyorsítótár-mód. Tervezése szerint kívül marad minden megosztott gyorsítótáron, az oldal szerkezetének pedig láthatóvá kell tennie ezt a határt a kódban. Az ábra egy gyorsítótárazott termékoldal kérési útvonalát mutatja.

![Kérési útvonal egy gyorsítótárazott B2B termékoldalhoz Négy doboz balról jobbra: a CDN edge a gyorsítótárazott HTML-vázat szolgálja ki; a kliens szigetek a böngészőben hidratálódnak; az ár API-t nem gyorsítótárazva, privát gyorsítótár-szabállyal hívják; a kosár- és fiókoldalak szerveroldalon renderelődnek, és soha nincsenek gyorsítótárazva. A személyre szabott adat soha nem jut el az első dobozba.](https://balazscsorba.com/images/blog/nuxt-caching-isr-commerce/diagram-6.webp?v=13c14f1393)

A kérési útvonal: a gyorsítótárazható HTML az edge-ről érkezik, a vevőtől függő minden más pedig nem gyorsítótárazott végpontra vagy a szerverre megy.

## Mit csinálnak valójában a Nuxt útvonalszabályai?

Az útvonalszabályok egy útvonalmintához rendelik a renderelési és gyorsítótárazási viselkedést. A Nuxt 4 dokumentáció többek között a redirect, proxy, ssr, cors, headers, swr, isr, prerender és noScripts szabályokat sorolja fel, a Nuxt pedig a megfelelő útvonalakat a Nitro által adott gyorsítótár-kezelőkbe csomagolja. A Nuxt 4.3 az ISR- és SWR-útvonalakhoz payload-kinyerést adott, így ezekhez a `_payload.json` fájlok is elkészülnek, és a HTML mellett gyorsítótárazhatók.

A három mód egy fontos pontban különbözik. Az `swr` gyorsítótár-fejléceket ad, és a választ a szerveren vagy fordított proxyn TTL-ig tárolja, lejárta után pedig a háttérben újragenerálja. Az `isr` ugyanígy viselkedik, egy kiegészítéssel: a válasz a CDN-gyorsítótárba is kerülhet, de a Nuxt dokumentáció ezt a támogató platformokra korlátozza, amelyeket Netlifyként vagy Vercelként nevez meg. A `prerender` a HTML-t build időben állítja elő, és a következő telepítésig megtartja.

Ebből az következik, hogy az `isr` nem hordozható név az edge-gyorsítótárazásra. A Vercelen a platform saját ISR-je áll mögötte. Egy Node-szerveren ugyanez a szabály a kiszolgálói rétegen stale-while-revalidate-et ad, a CDN-részt pedig külön kell felépíteni. A szabályt a platformra tekintettel írja meg, és a telepített környezet fejléceit ellenőrizze, ne a névben bízzon.

```
// nuxt.config.ts (sketch)
export default defineNuxtConfig({
  routeRules: {
    '/': { prerender: true },
    '/categories/**': { swr: 600 },                  // shared catalogue data, revalidated in the background
    '/products/**': { swr: 300 },                    // shell only; prices come from the client island
    '/cart/**': { ssr: true, headers: { 'cache-control': 'private, no-store' } },
    '/account/**': { ssr: true, headers: { 'cache-control': 'private, no-store' } },
  },
})
```

## Hogyan gyorsítótárazza a Nitro a választ?

A Nitro gyorsítótára az `ocache`\-re épül, és cserélhető tárolót használ. A gyorsítótár-opcióval rendelkező útvonalszabályok automatikusan a `defineCachedHandler` köré kerülnek, az `swr: true` pedig a `cache: { swr: true, maxAge }` rövidítése. Két alapértelmezés számít. A `maxAge` alapértelmezése egy másodperc, így a kifejezett kor nélküli bejegyzés szinte semmit sem ér, az útmutató pedig azt kéri, hogy minden gyorsítótárazni kívánt elemhez állítsa be. A `staleMaxAge` nélküli `swr: true` pedig nem ír TTL-t a tárolóba. A dokumentáció ezt ISR-mintának nevezi, vagyis a gyorsítótár növekedését a tároló háttere korlátozza, nem az idő.

A Nitro a gyorsítótár-fejléceket is maga állítja elő. A 60-as `maxAge` a `max-age=60` fejlécet adja. Az `swr` hozzáadja az `s-maxage=60` fejlécet, a `staleMaxAge: 600` pedig a `stale-while-revalidate=600` fejlécet. A `sendCacheControl: false` a bejegyzést a szerveren tartja anélkül, hogy a böngészők és a CDN-ek tudnának róla, ez akkor hasznos, ha az eredet olyan választ gyorsítótáráz, amelyet a megosztott rétegeknek nem szabad tárolniuk.

A kulcsok alapértelmezésben óvatosak. A lekérdezési paraméterek és a sütik nem jutnak el a kezelőig, és nem változtatják a kulcsot, így a `/page?a=1` és a `/page?utm=x` egy bejegyzést osztanak meg. Az `allowQuery` és az `allowCookies` ezt visszakapcsolja. A dokumentáció figyelmeztet, hogy az `allowCookies` `Vary: Cookie` fejlécet ad, ami a CDN-eken és a megosztott proxykon összeroppanthatja a találati arányt, és ahol lehet, az `allowQuery` segítségével az URL-be javasolja áthelyezni a döntést. A `set-cookie` fejlécet a gyorsítótárazás előtt eltávolítja, így a munkamenet-süti nem juthat el egy másik felhasználóhoz a gyorsítótáron át. Az a válasz, amelynek saját `Vary` fejléce a kulcson kívüli fejlécet nevez meg, kiszolgálódik, de nem tárolódik. A nyelv szintén kulcsdimenzió: minden nyelvi változatnak saját bejegyzés kell, a hreflang-linkek pedig csak olyan változatokra mutathatnak, amelyek ténylegesen kiszolgálhatók, ahogy azt a [többnyelvű Nuxt SEO hreflang-gel](https://balazscsorba.com/hu/blog/nuxt-i18n-multilingual-seo-hreflang) cikk tárgyalja.

Az eredeti gyorsítótár csak az első réteg, a CDN alapértelmezései pedig nem a HTML-ről szólnak. A Cloudflare zónagyorsítótára alapértelmezésben nem tárolja a HTML-t és a JSON-t; fájlkiterjesztés alapján dolgozik, és ha egy válasz nem tartalmaz `Cache-Control` vagy `Expires` fejlécet, állapotkódonként alapértelmezett TTL-t alkalmaz. A Vercel ISR minden csomagban elérhető, és a gyorsítótárazott tartalmat addig őrzi, amíg újra nem validálják, vagy 31 napig senki nem éri el. A Cloudflare Workers Cache egy újabb, a Workeren birtokolt lehetőség. Kulcsa tartalmazza a belépési pontot, az útvonalat és a lekérdezési karakterláncot, a Worker verzióját és a `ctx.props` értéket, de nem a hosztot és nem a HTTP-metódust. Teljes egészében a `Cache-Control` és a `CDN-Cache-Control` fejlécekkel vezérelhető, `Set-Cookie` és `Authorization` esetén automatikusan megkerüli a gyorsítótárat, és csak GET és HEAD kéréseket tárol. A változatok a pontos fejlécérték szerint tárolódnak, így az `Accept-Encoding: gzip, br` és a `br, gzip` külön bejegyzés, a `Vary: *` pedig kikapcsolja a gyorsítótárazást.

## Hogyan jutnak el a katalógusváltozások a gyorsítótárba?

A válaszokat íráskor címkézze, webhookról törölje címke szerint, a rövid max-age pedig legyen a tartalék. A Nitro a kiszolgálói rétegen nem kínál címke alapú törlést, ezért a címkék a CDN-en élnek. A Cloudflare-en a `Cache-Tag` fejléccel rendelkező válasz a vezérlőpultról vagy az API-n át címke szerint törölhető. A címkék kisbetű-nagybetű érzéketlenek, és nem tartalmazhatnak szóközt. Az összesített fejléc 16 KB-ra korlátozott, nagyjából ezer egyedi címkére, az API-címke pedig legfeljebb 1024 karakter lehet. Egy vezérlőpultos törlés legfeljebb 100 címkét fogad el, az API kérésenként 100 műveletet enged, Enterprise csomagban 500-at. Címke szerinti törlés után a következő kérés `CF-Cache-Status: MISS` értéket kap, a Tiered Cache mögött `EXPIRED`\-et, az oldal pedig az eredetiből töltődik újra.

```
// Purge the CDN cache for every product whose PIM record changed in this batch
const res = await fetch(`https://api.cloudflare.com/client/v4/zones/${zoneId}/purge_cache`, {
  method: 'POST',
  headers: { Authorization: `Bearer ${token}`, 'Content-Type': 'application/json' },
  body: JSON.stringify({ tags: changedSkus.map((sku) => `sku:${sku}`) }), // split into chunks of 100
})
if (!res.ok) throw new Error(`purge failed: ${res.status}`)  // fall back to the max age, then alert
```

A webhookra ugyanolyan gondossággal van szükség, mint bármely írási útvonalra: ellenőrizze az aláírást, deduplikálja az eseményeket, és fogja össze a lökésszerű érkezéseket, mert egy tömeges import egy perc alatt több ezer változást indíthat. A törlési hívások önmagukban is rate limit kockázatot jelentenek. A Workers Cache törlései mindig az ingyenes csomag törlési korlátait használják, ezért a Workeren birtokolt, gyakran törlő gyorsítótárnak kötegelnie kell őket.

![Törlés terjedése katalógusváltozás után Öt lépés balról jobbra: egy PIM-frissítés aláírt webhookot indít; a webhook törli a megfelelő gyorsítótár-címkét; a termék következő kérése kihagyás, és újratölti a gyorsítótárat. Törlés nélkül a stale-while-revalidate ablak a korábbi másolatot szolgálja ki, amíg a háttérfrissítés be nem fejeződik.](https://balazscsorba.com/images/blog/nuxt-caching-isr-commerce/diagram-21.webp?v=87caad98bd)

A törlés terjedése: a katalógusváltozás eltávolítja a címkézett bejegyzést, a következő kérés újratölti, a címke nélküli bejegyzés pedig elavultan szolgálódik ki, amíg a háttérfrissítés le nem zárul.

A címkék a pontos eszközt jelentik, az olcsó alternatíva a rövid max-age és a stale-while-revalidate. Az RFC 5861 a `stale-while-revalidate`\-et olyan kiterjesztésként határozza meg, amely lehetővé teszi, hogy a gyorsítótár egy meghatározott ideig elavult választ szolgáljon ki, miközben a háttérben újravalidál. A Vercel ISR ezt a viselkedést követi, a HTML-t és az adatpayloadokat atomikusan törli minden CDN-régióban, és sikertelen újravalidálás után 30 másodperces TTL-lel továbbra is elavult tartalmat szolgál ki. Az ár az, hogy a vevő rövid ideig láthatja az előző értéket, ezért az ablak hossza üzleti, nem technikai döntés.

## Hogyan gyorsítótárazhatók a vevői árakat mutató oldalak?

A váz legyen gyorsítótárazva, nem az ár. Egy termékoldal HTML-je mindenki számára ugyanaz, ezért megosztható. Az árat, a szerződéses kedvezményt és a kosárba helyezés állapotát egy kliens sziget kéri le egy olyan végpontról, amelyet soha nem osztunk meg, például a `GET /api/price?sku=…&customer=…` hívással, `Cache-Control: private` fejléccel. Egy konfigurált termék újabb réteget ad, mert az opciók megváltoztatják az árat és a rendelhetőséget; ezt az esetet a [headless termékkonfigurátorok B2B-ben](https://balazscsorba.com/hu/blog/headless-product-configurator-b2b) cikk tárgyalja, és ugyanez a határ itt is érvényes.

Ha a ár API nem elérhető, az oldalnak meghatározott tartalékra van szüksége, és a sorrend számít. A listaárat mutassa egy bejelentkezésre felszólító üzenettel a szerződéses ár helyett, soha ne egy másik vevőtől gyorsítótárazott árat. Tartalékként ne szolgáljon ki vevőspecifikus töredéket megosztott gyorsítótárból. Ha a készlet nem erősíthető meg, tiltsa le a kosárba helyezést, és naplózza a korlátozott állapotot, hogy megjelenjen a találati és a hibametrikákban.

**Egy nyilvános fejléc vevői adaton adatszivárgás**

A Shopify Hydrogen dokumentációja figyelmeztet: ha egy vevőspecifikus adatot visszaadó útvonalon nyilvános `Cache-Control` fejléc van, vagy nincs fejléc egyáltalán, a megosztott gyorsítótárak tárolhatják a renderelt oldalt, és más felhasználóknak is kiszolgálhatják, így a nevek, e-mail-címek és a rendelési előzmények kiderülnek. A dokumentált megoldás, hogy a vevői lekérdezéseknél a gyorsítótárazást kikapcsoljuk mind az al-kérés, mind az oldal szintjén.

Ez az EU-ban megfelelőségi kérdés is. Az a megosztott gyorsítótár, amely az egyik vevő oldalát egy másiknak szolgálja ki, személyes adatok nyilvánosságra hozatala, a GDPR ezt az 5. cikk (1) bekezdés f) pontjában rögzített integritás- és bizalmasság-elvvel, a 32. cikkben pedig az adatkezelés biztonságával kezeli. Élesítés előtt, és az útvonalszabályok minden módosítása után futtasson szivárgás-tesztet telepített környezetben, két teszt-fiókkal, az egyik másik árlistával. Több mint tíz év Vue, Nuxt, TypeScript, Node és PHP munka során, főleg B2B webáruházi és Spryker, illetve Pimcore PIM-platformokon, ez a kérdés kerül elő a leggyakrabban: mely útvonalak gyorsítótárazhatók, ha minden ár a bejelentkezett vevőtől függ?

## Hol nem érdemes a stale-while-revalidate-et használni?

Soha nem fizetési kapuk, nem a vásárlás pillanatbeli elérhetősége, és nem olyan érték esetén, amely olvasáskor kötelező. A stale-while-revalidate biztonságos ott, ahol egy rövid ideig téves érték elfogadható, és magától helyesbítődik, például a kategórialistáknál, a leírásoknál és a képeknél. A webáruházi csapatok ezeket az előre beállításokat már használják, a Hydrogen dokumentált gyorsítótár-stratégiái pedig jó referenciák: egy rövid, 10 másodperces stratégia, egy hosszú, egy óráig friss, majd elavult ablakkal, így összesen egy nap, valamint a `no-store` azokra az adatokra, amelyeket soha nem szabad újra felhasználni. Az alapértelmezett al-kérés stratégia `max-age=1`, 86 399 másodperces elavult ablakkal.

Az RFC 5861 a mechanizmust határozza meg, nem a szabályzatot. 2010-ben jelent meg, és a `stale-while-revalidate` és a `stale-if-error` fejléceket gyorsítótár-kiterjesztésekként vezette be; hogy egy adott gyorsítótár tiszteletben tartja-e őket, az a gyorsítótárnak a döntése. Az elavult ablak ezért a vevőknek tett ígéret, és annak a útvonalszabálynak a mellett kell állnia, amely betartatja. A határvonalak meghúzásához használja ezt a durva felosztást:

-   **Pénztár és kosár:** mindig `no-store`.
-   **Készlet a vásárlás pillanatában:** élőben olvassuk, vagy a rendelés létrehozásakor ellenőrzött hibát fogadunk el.
-   **Keresés feature flagekkel:** a flaget vegye be az URL-be, vagy ne gyorsítótárazza az eredményt.
-   **Katalógusadatok és tartalom:** stale-while-revalidate, írásban rögzített kerettel.

## Hogyan mérjük a találatokat, és mi szokott elromlani?

A fejlécekből mérjen, nem olyan vezérlőpultokról, amelyeket még nem állított be. A Vercel az `x-vercel-cache` fejlécben olyan értékeket ad, mint a HIT, MISS, STALE, PRERENDER, REVALIDATED és BYPASS, a dokumentáció pedig megjegyzi, hogy a dinamikus útvonalak és a futásidejű gyorsítótárból érkező lekérések gyakran MISS értéket mutatnak, akkor is, ha a futásidejű gyorsítótárból szolgálódnak ki. A Cloudflare a `CF-Cache-Status` fejlécet adja a HIT, MISS, BYPASS, DYNAMIC, EXPIRED, REVALIDATED, UPDATING és STALE értékekkel, és a HIT, STALE és UPDATING válaszokon beállítja az `Age` fejlécet. A Nitro saját `x-cache` fejlécet ad a HIT, STALE, REVALIDATED és MISS értékekkel. Ugyanaz az oldal tehát két állapotot jelezhet, egyet az eredeti rétegtől és egyet a CDN-től, és az a vezérlőpult, amely csak az egyiket olvassa, félrevezet.

-   **Hitelesített válaszok gyorsítótárazása.** Minden olyan válasz, amely sütitől vagy `Authorization` fejléctől függ, kifejezett private vagy no-store szabályt kíván. A Workers Cache ezeknél megkerüli a gyorsítótárat, de az a szabály a fontos, amelyet a többi gyorsítótár-rétegre ír.
-   **Vary-elburjánzás.** Egy `Vary: Cookie` vagy egy tág `Accept` fejléc addig darabolja a bejegyzéseket, amíg a találati arány össze nem omlik.
-   **Mérgezés a kulcs által nem fedett bemeneteken keresztül.** Minden olyan, ami megváltoztatja a választ anélkül, hogy a kulcsot megváltoztatná, például egy átírási vagy felülíró fejléc, vagy bekerül a kulcsba, vagy eltávolítódik, mielőtt a gyorsítótárhoz érne.
-   **Lekérdezési karakterlánc és sütik hiányoznak a kulcsból.** A Nitro alapértelmezésben mindkettőt kihagyja, ezért az a útvonal, amely egy lekérdezési paramétertől függ, `allowQuery` beállítást kíván, különben két URL egy bejegyzést oszt meg.
-   **Találatok, amelyek mégis pénzbe kerülnek.** Workersen a gyorsítótár-találat CPU-időt takarít meg, de továbbra is kérésnek számít, ezért a kérésszámla nem mozdul a találati aránnyal.
-   **Törlési viharok.** A törlési hívások sebességkorlátozottak, a Workers Cache törlései pedig az ingyenes csomag korlátait használják, ezért a tömeges importhoz kötegelés kell.

Az utolsó buktató egy sikeres indítás után köszönt be: az elavult tartalom, amelyet senki nem ellenőriz. A találati arány mellett kövesse a legrégebbi gyorsítótárazott katalógusbejegyzés korát is. Az elavulási keret csak akkor segít, ha valami jelzi a túllépését. Ugyanez igaz a generált tartalomra. A saját Nuxt oldalamon LLM-funkciók futnak, és LLM-pipeline-nal fordítottam le; ha a generált szöveg egy gyorsítótárazott oldalra kerül, egy elavult fordítás helyességi hiba, nem kozmetikai.

## Bevezetési ellenőrzőlista

A sorrend számít. Egy törlési útvonal haszontalan, ha a válaszok nem hordoznak címkét, a találati arány pedig megtévesztő, amíg a személyre szabás határa nem tiszta. Haladjon a lépéseken sorban, és mindegyiket az következő kapujaként kezelje.

1.  Soroljon be minden útvonalat a táblázat egyik osztályába, és írja mellé az elavulási keretet.
2.  Állítsa be az útvonalszabályt minden osztályhoz, és tegye egyértelművé az `isr` platformfüggő viselkedését.
3.  Írás közben címkézze minden katalógusválaszt, például SKU-nként és kategóriánként egyet.
4.  Kösse a PIM- vagy ERP-közzétételi eseményt egy aláírt webhookhoz, amely címke szerint kötegelve törli a bejegyzéseket.
5.  A fent leírt fejlécek alapján tegye láthatóvá a találati arányt rétegenként és a legrégebbi gyorsítótáras bejegyzés korát.
6.  Terheléses teszttel futtasson egy törlést csúcsforgalom idején, és jegyezze fel, mennyi idő alatt töltik újra a következő kérések a gyorsítótárat.
7.  Futtasson szivárgás-tesztet két fiókkal, az egyik másik árlistával, a telepített környezeten.

Ha egy webáruházi frontendet építene vagy javítana Nuxton, és azt szeretné, hogy a gyorsítótár-határ terhelés alatt is kitartson, nézze meg a [Vue és Nuxt munkámat](https://balazscsorba.com/hu/expertise/vue-nuxt-developer). A renderelési sebesség külön kérdés, saját metrikákkal, a [Nuxt Core Web Vitals](https://balazscsorba.com/hu/blog/nuxt-core-web-vitals-performance) cikkben tárgyalom.

## Források

1.  [Nuxt docs: rendering modes and route rules (v4)](https://nuxt.com/docs/4.x/guide/concepts/rendering)
2.  [Nuxt blog: Nuxt 4.3 release (ISR and SWR payload extraction)](https://nuxt.com/blog/v4-3)
3.  [Nitro docs: caching](https://nitro.build/guide/cache)
4.  [Cloudflare docs: default cache behavior](https://developers.cloudflare.com/cache/concepts/default-cache-behavior/)
5.  [Cloudflare docs: purge by tags](https://developers.cloudflare.com/cache/how-to/purge-cache/purge-by-tags/)
6.  [Cloudflare docs: Workers Cache](https://developers.cloudflare.com/workers/cache/)
7.  [Cloudflare docs: cache responses (CF-Cache-Status)](https://developers.cloudflare.com/cache/concepts/cache-responses/)
8.  [Vercel docs: incremental static regeneration](https://vercel.com/docs/incremental-static-regeneration)
9.  [Vercel docs: response headers (x-vercel-cache)](https://vercel.com/docs/headers/response-headers)
10.  [Shopify docs: Hydrogen caching strategies](https://shopify.dev/docs/storefronts/headless/hydrogen/caching)
11.  [RFC 5861: HTTP Cache-Control extensions for stale content](https://www.rfc-editor.org/rfc/rfc5861)
12.  [Regulation (EU) 2016/679 (GDPR), EUR-Lex](https://eur-lex.europa.eu/eli/reg/2016/679/oj)

## Gyakori kérdések

Mi a különbség a swr és az isr között a Nuxt útvonalszabályaiban?

Mindkettő stale-while-revalidate viselkedést ad a szerveren vagy fordított proxyn. A Nuxt dokumentáció szerint az isr a választ a támogató platformokon a CDN-gyorsítótárba is teheti, jelenleg a Netlify és a Vercel ilyen. Egy sima Node-szerveren a CDN-rész nem érvényesül, ezért ellenőrizze a telepítésének fejléceit.

Hogyan törölhető egy gyorsítótárazott Nuxt-oldal termékváltozáskor?

A Nitro a kiszolgálói rétegen nem kínál címkés törlést, ezért a választ a CDN-en Cache-Tag fejléccel címkézze, például SKU-nként egy címkével, és a termék változásakor webhookról törölje címke szerint. Ha a törlési hívás meghiúsul, a rövid max-age és a stale-while-revalidate legyen a tartalék.

Gyorsítótárazhatók a B2B vevői árakat mutató oldalak?

Igen, ha a gyorsítótárazott rész a közös váz, az ár pedig egy külön, soha nem megosztott végpontról érkezik. Jelölje ezt a végpontot privátként vagy no-store értékkel, és a vevőspecifikus HTML maradjon minden megosztott gyorsítótáron kívül, a CDN-gyorsítótárakat és a proxykat is beleértve.

Kerül pénzbe a Vercel ISR?

A Vercel szerint 2026 októberében az ISR minden csomagban elérhető. A CDN-gyorsítótár olvasása és írása ingyenes, a tartós tárolóról történő olvasás és írás viszont régiónként költséggel jár, amely a használati irányítópult ISR-szakaszában jelenik meg.

Csökkenti a számlát a Cloudflare Workers gyorsítótár-találata?

A kérésdíjat nem. A Cloudflare dokumentációja szerint a gyorsítótár-találat kérésnek számít, de nem fogyaszt CPU-időt. Magasabb találati arány tehát CPU-t takarít meg, a kérésdíjak viszont azonos forgalom mellett ugyanazok maradnak.

Írta: Csorba Balázs

Senior fullstack és AI mérnök Stájerországban – több mint 10 év Vue, Nuxt, Node.js és PHP, ma AI-ügynököknek építek eszközöket.

[Vue.js és Nuxt fejlesztés →](https://balazscsorba.com/hu/expertise/vue-nuxt-developer)[Rólam →](https://balazscsorba.com/hu/about)

## További cikkek

-   [Schema.org strukturált adatok B2B webshopokhoz: bejelentkezés mögötti árak, egységek és változatok](https://balazscsorba.com/hu/blog/schema-org-structured-data-b2b-shop)
-   [AI-asszisztens a B2B webshop ügyfélszolgálatához: eszközök, jogosultságok és átadás embernek](https://balazscsorba.com/hu/blog/ai-assistant-b2b-shop-customer-support)
-   [AI-csevegő UI Vue-ban és Nuxtban: akadálymentes streaming](https://balazscsorba.com/hu/blog/vue-ai-chat-ui-streaming-accessibility)
-   [LLM-fordítási pipeline i18n-hez: glosszárium, helyőrzők és review](https://balazscsorba.com/hu/blog/llm-translation-pipeline-i18n)

## Pont erre van szükséged?

Írj a projektedről vagy a pozícióról – szívesen hallok felőled.

[Lépj velem kapcsolatba](mailto:contact@balazscsorba.com) [Kapcsolódjunk LinkedInen](https://www.linkedin.com/in/balazs-csorba)