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

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.

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.

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 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.

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 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.

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. A renderelési sebesség külön kérdés, saját metrikákkal, a Nuxt Core Web Vitals cikkben tárgyalom.

Források

1. Nuxt docs: rendering modes and route rules (v4)
2. Nuxt blog: Nuxt 4.3 release (ISR and SWR payload extraction)
3. Nitro docs: caching
4. Cloudflare docs: default cache behavior
5. Cloudflare docs: purge by tags
6. Cloudflare docs: Workers Cache
7. Cloudflare docs: cache responses (CF-Cache-Status)
8. Vercel docs: incremental static regeneration
9. Vercel docs: response headers (x-vercel-cache)
10. Shopify docs: Hydrogen caching strategies
11. RFC 5861: HTTP Cache-Control extensions for stale content
12. Regulation (EU) 2016/679 (GDPR), EUR-Lex