Teljes oldalas HTML-gyorsítótár CDN-en kosár és bejelentkezés kizárásával

Scheo · 2026-10-26 · olvasási idő ~10 perc · Szerző: Schmidt Péter

A teljes oldalas HTML-gyorsítótár azt jelenti, hogy a CDN peremszervere a kész HTML-oldalt is eltárolja, és a következő látogatónak úgy adja ki, hogy a kérés el sem jut a WordPressig, a PHP-ig és az adatbázisig. Gyors, és sokat levesz a szerver válláról. Biztonságos viszont csak akkor, ha minden olyan oldalt és kérést kizársz, ahol a válasz látogatónként más. Ez a cikk a Cloudflare példáján mutatja meg, hol húzd meg a határt, és hogyan ellenőrizd a válaszfejlécekből, hogy jól működik.

A szövegben háromféle állítást különítünk el. A hivatalosan igazolt állítás a szolgáltató vagy a szoftver saját dokumentációjából származik. A saját tapasztalat az, amit WordPress- és WooCommerce-oldalak üzemeltetése közben rendszeresen látunk. A szakmai feltételezés pedig jól megalapozott következtetés, amit a te oldaladon érdemes külön ellenőrizned.

Mit jelent a teljes oldalas HTML-gyorsítótár a CDN-en?

Röviden. A CDN a képek, a CSS és a JavaScript mellett a dinamikusan előállított HTML-oldalt is eltárolja egy ideig, és a peremszerverről szolgálja ki, így a látogató gyorsabban kapja meg az első bájtot, a szerverednek pedig kevesebb kérést kell feldolgoznia.

Hivatalosan igazolt. A Cloudflare alapbeállításban a fájlkiterjesztés alapján dönt, és a HTML-t nem tárolja. A statikus fájlokat (például .css, .js, .jpg) gyorsítótárazza, a HTML-oldalakra adott válaszban viszont a cf-cache-status: DYNAMIC fejlécet látod. A HTML tárolásához két út van. Az egyik egy cache-szabály (Cache Rule), amelyben a kérést gyorsítótárazhatónak jelölöd (Eligible for cache). A másik WordPress-oldalaknál az Automatic Platform Optimization, röviden APO.

A különbség a gyakorlatban látványos. Egy WordPress-oldal HTML-jét a szervernek minden kérésnél újra össze kell raknia, ami bővítményektől és tárhelytől függően néhány száz ezredmásodperctől akár több másodpercig is tarthat. A peremszerverről kiadott oldal ezt a lépést kihagyja.

Mikor érdemes a teljes HTML-t is a peremszerveren tárolni?

Röviden. Akkor, ha az oldalaid túlnyomó része minden nem bejelentkezett látogatónak ugyanazt mutatja, és a lassúság vagy a szerverterhelés valódi gond. Ha az oldal nagy része személyre szabott, a teljes oldalas gyorsítótár több kockázatot hoz, mint hasznot.

Jó jelölt a tartalomoldal, a blog, a szolgáltatásoldal, a tudástár és a webshop termék- és kategóriaoldala, amíg azon nincs látogatóra szabott elem. Ilyenkor a gyorsítótár segítheti a betöltési időt és a Core Web Vitals mutatók közül főleg az első bájtig eltelt időt (TTFB) és a legnagyobb tartalmi elem megjelenését (LCP). Jól jön akkor is, ha sok automatikus kérés érkezik, például AI-crawlerektől, mert ezek a peremszerveren elakadnak, és nem terhelik az adatbázist.

Rossz jelölt a tagsági oldal, ahol szinte minden tartalom bejelentkezéshez kötött. Ugyanígy az az oldal, ahol a fejlécben bejelentkezve a látogató neve, nem bejelentkezve pedig például a helyi raktárkészlet jelenik meg, és ezt a szerver állítja elő, nem a böngésző. Saját tapasztalat. A legtöbb kis- és középvállalkozói WordPress-oldal az első csoportba tartozik, a webshopok pedig vegyesek. Termékoldalaik jól gyorsítótárazhatók, a vásárlási folyamat viszont soha.

Mit kell biztosan kizárni a gyorsítótárból?

Röviden. Mindent, ahol a válasz a látogatótól függ. Ez a bejelentkezett felhasználó, a kosár, a pénztár, a fiókoldal, a személyre szabott tartalom, az adminfelület és azok az űrlapok, amelyek nonce-szal védekeznek.

Bejelentkezett felhasználók

A WordPress bejelentkezéskor wordpress_logged_in_ kezdetű sütit állít be. Ha ez a süti jelen van, a kérés soha ne kerüljön a gyorsítótárba, és onnan se kapjon választ. Különben a bejelentkezett szerkesztő adminsávja vagy egy vásárló neve megjelenhet egy idegennek. A hozzászólók comment_author_ kezdetű sütijét is érdemes kizárni.

Kosár, pénztár és fiókoldal

WooCommerce-nél ezek az oldalak mindenkinek mást mutatnak. Hivatalosan igazolt. A WooCommerce dokumentációja kifejezetten kéri, hogy a kosár, a pénztár és a fiókom oldal ne kerüljön gyorsítótárba, és a woocommerce_items_in_cart, a woocommerce_cart_hash és a wp_woocommerce_session_ kezdetű sütit tartalmazó kéréseket kerüld meg. Az útvonalakat a saját beállításaidból vedd, mert magyar webshopnál ezek gyakran /kosar/, /penztar/ és /fiokom/ néven futnak, de bármi más is lehet.

Személyre szabott tartalom

Ide tartozik minden, amit a szerver a látogató alapján állít elő. Ilyen a földrajzi helyhez kötött ár vagy pénznem, a „legutóbb megtekintett termékek”, a nyelv sütiből történő kiválasztása, a B2B ügyfélárak, a kuponnal módosított ár. Hivatalosan igazolt. A Cloudflare a Vary fejlécet a tömörítésen kívül általában nem veszi figyelembe a gyorsítótár-kulcsban, vagyis a „sütitől függ a válasz” jelzést nem fogja magától kezelni. Ezt neked kell szabállyal megoldanod.

Nonce-t használó űrlapok

Hivatalosan igazolt. A WordPress nonce alapértelmezés szerint 12 és 24 óra között érvényes. Ha egy űrlapot tartalmazó oldal ennél tovább ül a gyorsítótárban, a beküldés hibára fut, mert a beágyazott nonce már lejárt. Szakmai feltételezés. Nem bejelentkezett látogatóknál a nonce a legtöbb esetben mindenkinek ugyanaz, így a gyorsítótárazás önmagában nem okoz biztonsági rést, a lejárat viszont igen. Ezért a peremszerveres élettartamot (Edge TTL) tartsd jóval 12 óra alatt az űrlapos oldalakon, vagy zárd ki őket.

Admin, bejelentkezés, REST és előnézet

A /wp-admin/, a /wp-login.php, a /wp-json/, az admin-ajax.php, a wc-ajax paraméteres kérések és az előnézeti linkek (preview=true) soha ne kerüljenek a gyorsítótárba.

Hogyan állítsd be Cloudflare cache-szabállyal lépésről lépésre?

Röviden. Egyetlen szabályt hozol létre, amely a HTML-t gyorsítótárazhatónak jelöli, de a feltételben kizárja a kényes útvonalakat és sütiket. Utána beállítod a peremszerveres és a böngészős élettartamot.

1. Írd össze a kizárandó útvonalakat (kosár, pénztár, fiók, admin, REST, keresés, ha a keresési eredmény személyre szabott).
2. Írd össze a kizárandó sütiket a böngésző fejlesztői eszközéből, bejelentkezve és teli kosárral is.
3. A Cloudflare felületén a Caching menü Cache Rules részében hozz létre új szabályt.
4. A feltételt kifejezésszerkesztőben add meg, az alábbi minta szerint.
5. Műveletként válaszd a gyorsítótárazhatót (Eligible for cache), és állíts be peremszerveres élettartamot.
6. A böngészős élettartamnál tartsd tiszteletben az eredeti szerver fejlécét, vagy adj meg rövid értéket.
7. Mentsd, majd teszteld az alábbi fejléces módszerrel.

Egy WooCommerce-es WordPress-oldal mintakifejezése így nézhet ki:

(http.host eq "pelda.hu" and not starts_with(http.request.uri.path, "/wp-admin") and not starts_with(http.request.uri.path, "/wp-json") and not http.request.uri.path in {"/wp-login.php" "/kosar/" "/penztar/" "/fiokom/"} and not http.request.uri.query contains "wc-ajax" and not http.request.uri.query contains "preview=true" and not http.cookie contains "wordpress_logged_in" and not http.cookie contains "comment_author" and not http.cookie contains "woocommerce_items_in_cart" and not http.cookie contains "woocommerce_cart_hash" and not http.cookie contains "wp_woocommerce_session")

A mintát a saját útvonalaidhoz igazítsd. A pénztár alatti végpontokat (például a fizetési visszatérő oldalt) is fedd le, erre a starts_with a biztosabb a pontos egyezésnél. Hivatalosan igazolt. A Cloudflare dokumentációja szerint a sütire épülő feltételek és egyes gyorsítótár-beállítások elérhetősége a csomagtól függ, ezért beállítás előtt nézd meg, nálad mi érhető el.

A böngészős élettartamról külön érdemes szólni. A peremszerveren tárolt oldalt egy kattintással vagy API-hívással ürítheted. A látogató böngészőjében tárolt HTML-hez viszont nem férsz hozzá. Ha ott hosszú élettartamot adsz, egy árváltozás napokig nem jut el a visszatérő látogatóhoz. Saját tapasztalat. HTML-nél a böngészős oldalon néhány perc vagy az eredeti szerver no-cache beállítása szokott jól működni, a peremszerveren pedig néhány óra.

Miben más az APO, és mikor elég az?

Röviden. Az APO a Cloudflare WordPressre szabott megoldása, amely a HTML-t gyorsítótárazza, a WordPress és a WooCommerce ismert sütijeinél magától megkerüli a gyorsítótárat, és a Cloudflare bővítményen keresztül tartalomfrissítéskor üríti a tárolt oldalt.

Hivatalosan igazolt. Az APO a bejelentkezett felhasználók és a WooCommerce kosársütijei alapján megkerüli a gyorsítótárat, és a működését külön fejléc jelzi. A cf-apo-via: tcache azt mutatja, hogy a választ az APO tárolójából kaptad, az origin érték pedig azt, hogy a kérés a szerverig ment. Ha az APO működik, a cf-cache-status önmagában félrevezető lehet, ezért mindkét fejlécet nézd.

Az APO akkor elég, ha szabványos WordPress-oldalad van, és a személyre szabás a megszokott sütikkel történik. Kevés lesz, ha egyedi bővítmény saját sütivel szab személyre, ha több pénznemet vagy nyelvet sütiből kezelsz, vagy ha tagsági bővítmény fut. Szakmai feltételezés. Ilyenkor az APO mellett kiegészítő szabály vagy a kényes útvonalak teljes kizárása kell, különben az APO jó eséllyel nem ismeri fel az egyedi sütit.

Hogyan teszteld a működést a válaszfejlécekkel?

Röviden. Kérd le ugyanazt az oldalt kétszer süti nélkül, majd egyszer bejelentkezett és egyszer kosársütivel. Süti nélkül a második kérésnél HIT státuszt és növekvő age értéket kell látnod, sütivel pedig BYPASS vagy DYNAMIC státuszt, age nélkül.

A legegyszerűbb eszköz a curl:

• curl -sI https://pelda.hu/termek/minta/ | grep -iE "cf-cache-status|age|cache-control|cf-apo-via"
• curl -sI -H "Cookie: woocommerce_items_in_cart=1" https://pelda.hu/termek/minta/
• curl -sI -H "Cookie: wordpress_logged_in_teszt=1" https://pelda.hu/
• curl -sI https://pelda.hu/kosar/

Hivatalosan igazolt. A cf-cache-status fontosabb értékei ezek:

• HIT, a választ a peremszerver adta a tárolójából.
• MISS, a tárolóban nem volt, a szervertől kérte le, és innentől tárolja.
• EXPIRED, lejárt a tárolt példány, újra lekérte.
• STALE vagy UPDATING, lejárt példányt adott ki, miközben frissít.
• BYPASS, egy szabály vagy az eredeti szerver fejléce miatt megkerülte a tárolót.
• DYNAMIC, a kérés nem gyorsítótárazható, tipikusan nincs rá szabály.

Az age fejléc azt mutatja másodpercben, mióta ül a példány a tárolóban. Ha két kérés között nő, a tároló működik. Ha egy kosár- vagy fiókoldalon bármikor age fejlécet látsz, az hiba, és azonnal javítani kell. Böngészőben ugyanezt a fejlesztői eszközök Hálózat lapján látod, de ott a böngésző saját gyorsítótára is beleszólhat, ezért a döntő tesztet curl-lel vagy privát ablakban végezd.

Milyen tipikus hibák jönnek elő, és hogyan előzöd meg őket?

Röviden. A leggyakoribb a más vásárló kosarának vagy nevének megjelenése, az elavult ár, a lejárt nonce miatti űrlaphiba és a feleslegesen széttöredezett gyorsítótár. Mindegyik megelőzhető pontos kizárással, rövid élettartammal és ürítési renddel.

Más vásárló kosara vagy neve jelenik meg

Ez a legsúlyosabb hiba, mert személyes adatot szivárogtathat ki. Akkor fordul elő, ha a kosársütivel érkező kérésre adott választ a peremszerver eltárolja. Saját tapasztalat. Gyakran nem a kosároldal a bűnös, hanem a fejléc kosárikonja, amelyet a sablon szerveroldalon rajzol ki a termékoldalon. Ha a kosársüti nincs kizárva, az első vásárló darabszáma mindenkinek megjelenik. A megoldás a sütis kizárás és az, hogy a kosár darabszámát a böngésző kérje le külön, gyorsítótár nélküli kéréssel.

Elavult ár vagy készlet

Ha a termék ára változik, de a tárolt oldal még a régit mutatja, a vásárló a pénztárban mást lát, mint a termékoldalon. Ez bizalmi és fogyasztóvédelmi kockázat is. Saját tapasztalat. A WordPress-felületen mentett termék után a Cloudflare bővítmény vagy az APO jellemzően üríti az oldalt, tömeges importnál, ERP-szinkronnál vagy közvetlen adatbázis-módosításnál viszont ez sokszor elmarad. Ilyenkor az importfolyamat végére tegyél API-alapú ürítést, és tartsd rövidebbre a termékoldalak élettartamát.

Lejárt nonce, sikertelen űrlap

Ha a kapcsolati vagy hírlevél-űrlap időnként „lejárt link” hibát ad, a gyorsítótárban túl régi nonce ül. Csökkentsd az élettartamot, zárd ki az űrlapos oldalt, vagy használj olyan űrlapmegoldást, amely a tokent a böngészőből kéri le friss kéréssel.

Széttöredezett gyorsítótár a kampányparaméterek miatt

A utm_source és a fbclid paraméter minden változata külön gyorsítótár-kulcsot hozhat létre, ezért a kampányforgalom szinte mindig MISS lesz. Hivatalosan igazolt. A Cloudflare cache-szabályban a gyorsítótár-kulcs testre szabható, a mérési paraméterek kihagyhatók belőle. Csak olyan paramétert hagyj ki, amely biztosan nem változtatja a tartalmat.

Hibaoldalak és cache deception

Ne tárold sokáig az 5xx választ, mert egy rövid szerverleállás után a hibaoldal órákig megmaradhat. A cache deception támadásnál pedig valaki egy személyes oldalt statikus fájlnak álcázott URL-lel próbál a tárolóba juttatni (például /fiokom/stilus.css). Hivatalosan igazolt. A Cloudflare erre külön védelmet kínál (Cache Deception Armor), amely ellenőrzi, hogy a kiterjesztés egyezik-e a tartalom típusával.

Mit nézz át élesítés előtt egy ellenőrzőlistával?

Röviden. Élesítés előtt minden kizárást tesztelj sütivel és süti nélkül, és legyen kész ürítési terved az árváltozásokra.

• Megvan a kizárt útvonalak teljes listája, a fizetési visszatérő oldalakkal együtt.
• Megvan a kizárt sütik listája, egyedi bővítmények sütijeivel együtt.
• Süti nélkül a második kérés HIT, az age nő.
• Bejelentkezve és kosársütivel BYPASS vagy DYNAMIC, age nélkül.
• A kosár, a pénztár és a fiók oldalán soha nincs age fejléc.
• A HTML böngészős élettartama rövid.
• Az űrlapos oldalak élettartama 12 óra alatt van, vagy ki vannak zárva.
• Termékmentés és tömeges import után is ürül a tárolt oldal.
• A kampányparaméterek nem töredezik a gyorsítótárat.
• Egy teszt-vásárlás végigmegy két külön böngészőből, és egyik sem látja a másik kosarát.

A teljes oldalas gyorsítótár jó eséllyel érezhetően gyorsít, de semmilyen helyezést vagy konverziós eredményt nem garantál. A haszna a gyorsabb kiszolgálásban és a kisebb szerverterhelésben mérhető, a kockázata pedig a rosszul megírt kizárásban rejlik. Ezért a beállítás nem egyszeri munka. Minden új bővítmény, sablonfrissítés vagy fizetési mód után érdemes a fenti teszteket újra lefuttatni.

Források és további olvasnivalók

• Cloudflare dokumentáció, Cache Rules
• Cloudflare dokumentáció, Cloudflare cache responses (cf-cache-status értékek)
• Cloudflare dokumentáció, Default cache behavior
• Cloudflare dokumentáció, Automatic Platform Optimization for WordPress
• Cloudflare dokumentáció, Cache Deception Armor
• WooCommerce dokumentáció, Configuring caching plugins
• WordPress Developer Resources, Nonces
• MDN Web Docs, Cache-Control és Age HTTP-fejléc
• IETF RFC 9111, HTTP Caching
• Google Search Central, Core Web Vitals és oldalélmény