WordPress cache: teljes útmutató

A WordPress cache azt jelenti, hogy az oldalad egyszer már legenerált eredményét (HTML-t, adatbázis-lekérdezést, statikus fájlt) eltárolod, és a következő látogatónak ezt adod ki újraszámolás helyett. Így kevesebb PHP- és adatbázismunka kell, gyorsabb lesz a szerverválasz és a betöltés. A jó beállítás rétegekből áll: oldalcache, objektumcache, böngészőcache és CDN, mindegyik a saját feladatára.

Alapfogalmak

A WordPress alapból dinamikus rendszer. Minden kérésnél lefut a PHP, betöltődnek a bővítmények és a téma, a rendszer lekérdezéseket küld a MySQL vagy MariaDB adatbázisnak, majd összerakja a HTML-t. Ez egy látogatónál nem gond, de ha száz ember kéri le ugyanazt a blogbejegyzést, a szerver százszor végzi el ugyanazt a munkát, holott az eredmény mind a százszor azonos. A cache ezt a felesleges ismétlést szünteti meg.

Érdemes tisztán látni, hogy a "cache" nem egyetlen dolog. Több réteg létezik, és mindegyik máshol tárol, más élettartammal, más célra. Ha összekevered őket, könnyen előfordul, hogy két bővítmény ugyanazt csinálja, vagy hogy egy fontos réteg teljesen kimarad.

A legfontosabb rétegek

Réteg	Mit tárol?	Hol él?	Mire jó?
Oldalcache (page cache)	Kész HTML-oldalt	Szerver lemezén vagy memóriájában, illetve proxyban	Kihagyja a PHP-t és az adatbázist a nem bejelentkezett látogatóknál
Objektumcache	Adatbázis-lekérdezések eredményét, beállításokat	Memóriában (például Redis vagy Memcached)	Gyorsítja a dinamikus oldalakat, az admint és a webshopot
Opcode cache	Lefordított PHP-kódot	A PHP folyamat memóriájában (OPcache)	Nem kell minden kérésnél újrafordítani a PHP-fájlokat
Böngészőcache	Képeket, CSS-t, JS-t, betűtípusokat	A látogató gépén	Visszatérő látogatónál nem kell újra letölteni a fájlokat
CDN cache	Statikus fájlokat, néha teljes HTML-t	A látogatóhoz közeli szervereken	Csökkenti a földrajzi távolságból adódó késleltetést

Cache találat és cache tévesztés

Két fogalmat a mérésnél és a hibakeresésnél is folyton használni fogsz. A cache hit (találat) azt jelenti, hogy a kért tartalom ott volt a tárban, és onnan szolgálták ki. A cache miss (tévesztés) azt, hogy nem volt ott, ezért a rendszernek le kellett generálnia, és jó esetben utána eltárolta. Egy jól beállított oldalnál a nyilvános, ritkán változó oldalak túlnyomó része találat.

TTL, ürítés, előmelegítés

TTL (time to live): mennyi ideig érvényes egy tárolt elem. Utána lejár, és a következő kérés újragenerálja.
Ürítés (purge, invalidálás): a tárolt elem szándékos törlése, például amikor frissítesz egy bejegyzést. Ha ez nem működik, a látogatók a régi változatot látják.
Előmelegítés (preload, warmup): a cache előre feltöltése, hogy ne az első valódi látogató kapja a lassú, generált választ.

Mi nem cache?

Gyakori tévhit, hogy a CSS- és JS-minifikálás, a képtömörítés vagy a késleltetett betöltés (lazy load) is "cache". Ezek optimalizációk, amelyeket sok cache-bővítmény is tartalmaz, de más problémát oldanak meg. A cache az ismételt munkát spórolja meg, a minifikálás a fájlméretet csökkenti. Ha egy oldal a minifikálás után elromlik, az nem cache-hiba, és máshol kell keresni az okát. Ezt a különbséget a hibakeresésnél is jó fejben tartani, mert gyorsan leszűkíti a lehetséges okokat.

A cache a szélesebb WordPress SEO munka része: a gyors szerverválasz önmagában nem hoz helyezést, de a lassú oldal a feltérképezést és a felhasználói élményt is ronthatja.

Hogyan működik?

A cache működését akkor érted igazán, ha végigköveted egy kérés útját. Nézzük meg, mi történik, amikor egy látogató megnyitja az egyik bejegyzésedet egy olyan szerveren, ahol több réteg is be van kapcsolva.

Egy kérés útja lépésről lépésre

Böngésző: a böngésző először megnézi, van-e már nála érvényes példány a fájlokból. Ha a CSS vagy egy kép még friss a saját tárában, le sem kéri újra.
CDN: ha használsz CDN-t, a kérés a legközelebbi csomóponthoz fut be. Ha ott van tárolt példány, onnan érkezik a válasz, a saját szervered el sem éri a kérés.
Szerveroldali oldalcache: ha a kérés eljut a szerverig, a webszerver vagy egy bővítmény megnézi, létezik-e kész HTML ehhez az URL-hez. Ha igen, PHP-futtatás nélkül, vagy csak minimális PHP-val kiszolgálja.
PHP és opcode cache: ha nincs kész oldal, elindul a WordPress. Az OPcache miatt a PHP-fájlokat nem kell újra lefordítani.
Objektumcache: a WordPress lekérdezései előbb a memóriabeli tárban keresik az eredményt, és csak akkor fordulnak az adatbázishoz, ha ott nincs meg.
Generálás és tárolás: elkészül a HTML, a rendszer elmenti az oldalcache-be, és kiküldi a látogatónak.

Látható, hogy minél korábbi lépésnél van találat, annál kevesebb munka marad a szerverre. Ezért egy statikus blogbejegyzésnél az oldalcache a legnagyobb nyereség, egy kosaras webshopoldalnál viszont az objektumcache, mert ott az oldalcache-t sokszor eleve ki kell kapcsolni.

Mikor kerüli meg a rendszer a cache-t?

Az oldalcache nem adhatja ki ugyanazt a HTML-t mindenkinek. A legtöbb megoldás alapból kihagyja a cache-t ezekben az esetekben:

bejelentkezett felhasználóknál (adminsáv, személyes adatok),
kosár, pénztár és fiókoldalaknál webshopban,
POST kéréseknél, például űrlapküldésnél,
bizonyos sütik jelenlétekor, ha a tartalom a sütitől függ,
egyes lekérdezési paramétereknél, attól függően, hogyan van beállítva.

Ürítés: honnan tudja a rendszer, hogy valami megváltozott?

Ez a cache legkényesebb része. Amikor frissítesz egy bejegyzést, nem csak az a bejegyzés változik. Változhat a főoldal (ha ott listázod), a kategóriaarchívum, a címkeoldalak, a szerzői oldal, az RSS-hírcsatorna és az oldaltérkép is. Egy jó cache-megoldás ezeket a kapcsolódó oldalakat is üríti. Ha a beállításod csak az adott URL-t törli, a főoldalon még órákig a régi cím látszhat.

Ha a cache több rétegben él, az ürítésnek is minden rétegre ki kell terjednie. Gyakori helyzet, hogy a bővítmény rendben törli a saját tárát, de a CDN vagy a tárhelyszolgáltató szerverszintű cache-e továbbra is a régi oldalt adja.

Szemléltető példa: egy kis céges blog

Vegyünk egy kitalált oldalt: egy könyvelőiroda blogja, napi néhány száz látogatóval, kéthetente új cikkel, kapcsolati űrlappal. Itt a teljes oldalcache a nyilvános oldalakon szinte minden kérést kiszolgál, mert a tartalom ritkán változik. Az űrlapoldalt viszont figyelni kell: ha az űrlap biztonsági tokent (nonce) használ, és az oldal túl sokáig marad a cache-ben, a token lejárhat, és a beküldés hibára fut. A megoldás az, hogy ennél az oldalnál rövidebb TTL-t állítasz, vagy kizárod a cache-ből. Ez a fajta oldalankénti gondolkodás adja a jó beállítás lényegét.

Fő módszerek

A cache-t háromféleképpen kaphatod meg: a tárhelyszolgáltatótól szerverszinten, WordPress-bővítménnyel, vagy saját szerverbeállítással. A jó döntés nem az, hogy melyik "a legjobb", hanem hogy melyik illik a tárhelyedhez és az oldalad típusához.

1. Tárhelyszintű cache

Sok menedzselt WordPress-tárhely saját oldalcache-t futtat a webszerver szintjén (például Nginx alapú megoldással vagy reverse proxyval). Ennek előnye, hogy a kérés PHP-ig sem jut el, ezért általában gyorsabb, mint egy bővítményes megoldás. Hátránya, hogy kevésbé tudod finomhangolni, és az ürítéshez gyakran a szolgáltató saját bővítménye kell. Ha a tárhelyed ilyet kínál, először ezt nézd meg, mert erre építve kell kiválasztani a többit.

2. Cache-bővítmény

Ha nincs szerverszintű cache, egy bővítmény statikus HTML-fájlokat készít, és ezeket adja ki. A bővítmények többsége optimalizálási funkciókat is hoz (minifikálás, fájlok összevonása, késleltetett betöltés). Itt érdemes óvatosan bekapcsolni a lehetőségeket egyenként, mert pont ezek okozzák a legtöbb törést.

3. Objektumcache Redisszel vagy Memcacheddel

Az objektumcache-hez a szerveren futnia kell egy memóriabeli tárnak, és a WordPressnek kell egy úgynevezett drop-in fájl (object-cache.php), amely átirányítja a lekérdezéseket. Ez akkor hoz sokat, ha sok a dinamikus, nem cache-elhető kérés: webshop, tagsági oldal, fórum, sok bejelentkezett felhasználó, nehéz admin. Egy egyszerű bemutatkozó oldalnál a hatása kisebb lehet, mert ott az oldalcache már úgyis kiszolgál szinte mindent.

4. Böngészőcache és CDN

A böngészőcache a HTTP-fejlécekkel működik (Cache-Control, Expires, ETag). A statikus fájlokra hosszú élettartamot szokás adni, a HTML-re rövidet vagy semennyit. Hosszú élettartamnál fontos, hogy a fájlnév vagy a verzióparaméter változzon frissítéskor, különben a visszatérő látogató a régi CSS-t kapja. A CDN a statikus fájlokat a látogatóhoz közel szolgálja ki, ami főleg nemzetközi közönségnél számít.

Döntési szabály: melyik kombináció kell neked?

Oldaltípus	Oldalcache	Objektumcache	CDN
Bemutatkozó oldal, kevés változás	Igen, ez a fő réteg	Opcionális	Csak külföldi közönségnél fontos
Tartalmas blog, hírportál	Igen, jó ürítéssel	Hasznos nagy forgalomnál	Ajánlott
Webshop	Igen, de kosár, pénztár, fiók kizárva	Erősen ajánlott	Statikus fájlokra ajánlott
Tagsági oldal, LMS	Csak nyilvános részekre	Erősen ajánlott	Statikus fájlokra ajánlott

Egyszerű szabály: egy réteghez egy eszköz. Ha a tárhely már ad oldalcache-t, ne kapcsolj be mellé egy második oldalcache-t bővítményből. Ha optimalizálni szeretnél, használd a bővítmény optimalizálási részét, de az oldalcache-funkcióját hagyd kikapcsolva, ha a szolgáltató ezt javasolja.

Bevezetési workflow

Mérd meg a kiinduló állapotot (lásd a Mérés részt), és ments biztonsági másolatot.
Derítsd ki, milyen cache-t ad a tárhely.
Kapcsold be az oldalcache-t, és ellenőrizd kijelentkezve, inkognitó ablakban.
Állítsd be a kizárásokat (kosár, pénztár, fiók, űrlapok).
Ha kell, kapcsold be az objektumcache-t, és nézd meg az admin sebességét.
Egyenként kapcsold be az optimalizálásokat, minden lépés után teszteld a fő oldalakat.
Mérd újra ugyanazzal a módszerrel, és vesd össze.

Gyakori hibák

A cache-problémák többsége nem a technológiából, hanem a rossz beállításból vagy a rétegek ütközéséből adódik. Az alábbi hibák visszatérő minták, és szinte mindegyikre van egyszerű ellenőrzés.

Dupla oldalcache

Két réteg ugyanazt a munkát végzi: a tárhely szerverszintű cache-e és egy bővítmény is HTML-t tárol. Ebből furcsa jelenségek lesznek: frissítés után az egyik réteg ürül, a másik nem, és a látogatók véletlenszerűen régi vagy új változatot látnak. A hibakeresés is nehéz, mert nem tudod, melyik réteg szolgált ki. A megoldás: döntsd el, melyik a fő oldalcache, a másikat kapcsold ki.

Személyes tartalom a cache-ben

Ez a legsúlyosabb hiba. Ha a kosár, a fiókoldal vagy egy "Üdv, Péter" feliratot tartalmazó oldal bekerül a nyilvános cache-be, a következő látogató más ember adatait láthatja. Webshopnál mindig ellenőrizd kijelentkezve és két különböző böngészőben, hogy a kosár tartalma nem "öröklődik".

Elromlott dizájn vagy funkció optimalizálás után

A JS-fájlok összevonása, késleltetése vagy aszinkron betöltése sokszor eltöri a menüt, a csúszkát, az űrlapot vagy a sütibanner működését. Ez technikailag nem cache-hiba, de a cache-bővítmény beállításai között kapcsolod be, ezért ide tartozik. Ellenszer: egyenként kapcsold be a funkciókat, és a hibás szkriptet zárd ki az optimalizálásból.

Elmaradó ürítés

Frissítetted a bejegyzést, de a főoldal és a kategóriaoldal még a régi címet mutatja.
Módosítottad a CSS-t, de a visszatérő látogatók a régi kinézetet kapják, mert a fájlnév nem változott.
Kiürítetted a bővítmény cache-ét, de a CDN továbbra is a régi példányt adja.

Lejárt biztonsági tokenek

Ahogy a példában láttad, a WordPress nonce értékei korlátozott ideig érvényesek. Ha egy űrlapot tartalmazó oldal túl hosszú ideig van a cache-ben, a beküldés "érvénytelen kérés" jellegű hibával elszállhat. Rövidebb élettartam, kizárás vagy olyan űrlapmegoldás segít, amely a tokent dinamikusan kéri le.

SEO-t érintő mellékhatások

A cache az SEO-beállításokat is befolyásolhatja. Ha módosítod a title-t vagy a meta leírást, de az oldal nem ürül, a keresőrobot egy ideig a régi változatot kaphatja. Hasonló a helyzet az oldaltérképpel és a robots.txt-vel, ha ezeket is cache-eli valamelyik réteg. Ha SEO-bővítményt használsz, az alapbeállításokról a Yoast SEO, a Rank Math és az All in One SEO útmutatóban olvashatsz, a cache-nél pedig azt figyeld, hogy a módosításaid ténylegesen megjelennek-e a kiszolgált HTML-ben.

Tévhit: "több cache, gyorsabb oldal"

Nem. A rétegek csak akkor adódnak össze, ha mindegyik más feladatot lát el. Két oldalcache, két minifikáló vagy két késleltetett betöltés nem gyorsít, hanem ütközik. A jó cél az, hogy minden rétegnek pontosan egy gazdája legyen.

Hibakeresési ellenőrzőlista

Inkognitó ablakban, kijelentkezve nézed az oldalt?
Melyik réteg szolgálta ki? Nézd meg a válaszfejléceket.
Kiürítetted mindegyik réteget (bővítmény, tárhely, CDN)?
Ha kikapcsolod az optimalizálásokat, megszűnik a hiba?
Ha kikapcsolod a cache-t, megszűnik a hiba? Ha nem, máshol van az ok.

Mérés

Cache-t mérés nélkül beállítani találgatás. Két dolgot kell tudnod: valóban a cache szolgál-e ki, és ez mennyit javított a sebességen. A kettő külön kérdés, és külön módszert igényel.

Működik a cache? A fejlécek ellenőrzése

A böngésző fejlesztői eszközeiben (Hálózat fül) nyisd meg a HTML-kérést, és nézd meg a válaszfejléceket. Sok cache-megoldás és CDN ad olyan fejlécet, amelyből kiderül, hogy találat vagy tévesztés történt (például egy HIT vagy MISS értékkel). Hogy pontosan melyik fejléc, az a szolgáltatótól függ, ezért a tárhelyed vagy a bővítményed dokumentációjában nézd meg. Egy másik jel: sok bővítmény HTML-megjegyzést tesz az oldal forráskódjának végére, amely a cache-elés idejét mutatja.

Parancssorból is gyorsan ellenőrizheted: kérd le kétszer egymás után ugyanazt az URL-t, és nézd meg a fejléceket. Az első kérés lehet tévesztés, a másodiknak jellemzően már találatnak kell lennie.

Mennyit gyorsított? A fontos mutatók

Mutató	Mit mutat?	Mennyire függ a cache-től?
TTFB (Time to First Byte)	Mennyi idő alatt érkezik meg a válasz első bájtja	Nagyon, az oldalcache ezen javít a legtöbbet
LCP (Largest Contentful Paint)	Mikor jelenik meg a legnagyobb látható elem	Részben, a TTFB beleszámít
INP (Interaction to Next Paint)	Mennyire gyorsan reagál az oldal az interakcióra	Kevéssé, inkább a JS mennyisége számít
CLS (Cumulative Layout Shift)	Mennyire ugrál az elrendezés	Alig, a cache nem ezt oldja meg

Ebből is látszik, hogy a cache leginkább a szerverválasz idején javít. Ha az LCP-d a hatalmas főkép miatt rossz, a cache egyedül nem fogja megoldani.

Laboradat és terepadat

A laboradat egy egyszeri, szimulált mérés (például PageSpeed Insights laborrésze vagy a böngésző Lighthouse-eszköze). Gyors, megismételhető, és a változtatás hatását azonnal mutatja. A terepadat valódi látogatóktól származik (a PageSpeed Insights ezt is mutatja, ha van elég adat, illetve a Search Console Core Web Vitals jelentése). Ez lassabban frissül, ezért egy beállítás hatása itt csak később látszik.

Szemléltető mérési napló

Az alábbi számok kitaláltak, csak a módszert szemléltetik. Egy blogbejegyzés TTFB-jét öt mérés mediánjával nézzük, mindig ugyanarról a helyről, kijelentkezve:

Állapot	TTFB medián (szemléltető)	Megjegyzés
Cache nélkül	900 ms	Minden kérésnél fut a PHP és az adatbázis
Oldalcache, első kérés	950 ms	Tévesztés, ekkor generálódik és mentődik
Oldalcache, ismételt kérés	150 ms	Találat, kész HTML-t kap a látogató

A tanulság: mindig ismételt mérést nézz, és ne egyetlen futásból vonj le következtetést, mert az első kérés torzít.

Mérési ellenőrzőlista

Ugyanazt az URL-t, ugyanarról a helyről, ugyanazzal az eszközzel méred előtte és utána.
Legalább három-öt futás mediánját nézed.
Kijelentkezve mérsz, különben a cache-t ki is kerülheti a rendszer.
Külön méred a főoldalt, egy bejegyzést, egy archívumot és webshopnál egy termékoldalt.
Feljegyzed, melyik beállítást mikor változtattad, hogy a terepadat változását vissza tudd kötni.

Kapcsolódó részletes útmutatók

A cache a WordPress-oldal technikai alapjainak egyik eleme, de a keresőoptimalizálás ennél jóval tágabb terület. Ha a gyorsítás után a tartalom, a meta adatok, az oldaltérkép és a strukturált adatok következnek, az alábbi útmutatók segítenek továbblépni. Mindegyiknél érdemes észben tartani, amit itt a cache ürítéséről olvastál: minden SEO-módosítás után ellenőrizd, hogy a változás a kiszolgált oldalon is megjelent-e.

Ha az alapokkal kezdenéd

A teljes kép áttekintéséhez a WordPress SEO főoldala és a teljes útmutató a jó kiindulópont. Itt azt látod, hogyan illeszkedik a sebesség a tartalom, a technikai beállítások és a belső linkelés közé, és milyen sorrendben érdemes ezeket rendbe tenni.

Ha SEO-bővítményt választasz vagy állítasz be

A SEO-bővítmények kezelik a title-t, a meta leírást, a kanonikus URL-t és az oldaltérképet. Ezek mind olyan elemek, amelyeknél a cache miatt késhet a változás megjelenése, ezért a bővítmény beállítása után mindig ürítsd a cache-t, és ellenőrizd a forráskódot. Válaszd azt az útmutatót, amelyik a te bővítményedhez tartozik:

Rövid összefoglaló ellenőrzőlista a továbblépéshez

Tisztázd, milyen cache-t ad a tárhelyed, és rétegenként egy eszközt használj.
Zárd ki a személyes és a tranzakciós oldalakat az oldalcache-ből.
Ellenőrizd, hogy frissítéskor a kapcsolódó oldalak és a CDN is ürülnek.
Mérd a TTFB-t és a Core Web Vitals mutatókat előtte és utána, ismételt futásokkal.
SEO-módosítás után ürítsd a cache-t, és nézd meg a kiszolgált HTML-t.

Ha ezt az öt pontot rendszeresen végigveszed, a cache nem titokzatos fekete doboz lesz, hanem kiszámítható eszköz, amelynek a hatását mérni és indokolni is tudod.