Rövid válasz elöljáróban: a WordPress gyorsítótár-bővítmény azt gyorsítja, ami ismétlődik. Ha ugyanazt az oldalt ugyanabban a formában sokan kérik le, a cache megspórolja a PHP-futást és az adatbázis-lekérdezéseket, és egy kész HTML-választ ad vissza. Amit viszont nem tud megspórolni, az az első, még nem gyorsított kérés. Az pontosan olyan lassú lesz, amilyen lassú a szervered, a sablonod és az adatbázisod.
Ez az egy mondat a cikk lényege, a többi ennek a kibontása: melyik réteg mit gyorsít, hol romlik el, mit kell kizárni belőle, és hogyan veszed észre, ha elavult tartalmat szolgál ki.
Milyen rétegei vannak a gyorsítótárazásnak, és melyik mit gyorsít?
Rövid válasz: öt, egymástól független réteg dolgozik egyszerre. Az oldalcache a kész HTML-t, az objektumcache az adatbázis-eredményeket, az opcode cache a lefordított PHP-t, a böngészőcache a statikus fájlokat, a CDN pedig a földrajzi távolságot rövidíti le. Egyik sem helyettesíti a másikat.
Oldalcache (page cache)
A legnagyobb ugrást ez adja. A bővítmény lementi a legenerált HTML-t, és a következő látogatónak azt adja vissza, PHP-futás nélkül. Egy tipikus bemutatkozó oldalon vagy blogbejegyzésen ez a szerveroldali válaszidőt nagyságrenddel tudja csökkenteni. Hivatalosan igazolt: a WordPress core támogatja az oldalcache bekapcsolását a WP_CACHE konstanssal és az advanced-cache.php drop-in fájllal, ez dokumentált mechanizmus.
Ahol elromlik: a személyre szabott tartalomnál. Ha egy bejelentkezett felhasználó nevét vagy kosarát is elmenti, azt fogja látni a következő látogató is.
Objektumcache (object cache)
A WordPress alapból is gyorsítótárazza az adatbázis-eredményeket, de csak egyetlen kérésen belül. A tartós objektumcache (Redis vagy Memcached) ezt kérések között is megőrzi. Ott hoz sokat, ahol az oldalcache nem tud dolgozni: bejelentkezett felhasználóknál, kosaras oldalakon, admin felületen, WooCommerce-nél.
Saját tapasztalat: nagyobb webshopoknál sokszor nem az oldalcache hiányzik, hanem a tartós objektumcache. A vendégoldalak repülnek, a pénztár viszont vánszorog, mert ott minden kérés újra megkérdezi az adatbázist. Ahol elromlik: ha a Redis megtelik és rossz kiürítési szabállyal dolgozik, vagy ha egy bővítmény hibásan tárolja a felhasználóhoz kötött adatot globális kulcs alatt.
Opcode cache (OPcache)
Ez nem bővítmény, hanem PHP-szintű dolog: a PHP-fájlok lefordított változatát tartja a memóriában, hogy ne kelljen minden kérésnél újraértelmezni. Hivatalosan igazolt: a PHP hivatalos dokumentációja szerint az OPcache a PHP 5.5 óta a nyelv része, és a legtöbb modern tárhelyen alapból be van kapcsolva.
Ahol elromlik: frissítés után. Ha a szerver régi, gyorsítótárazott kódot futtat, miközben a fájl már új, furcsa, megmagyarázhatatlan hibákat kapsz. Ilyenkor a PHP-FPM újraindítása vagy az OPcache ürítése a megoldás.
Böngészőcache
Itt a látogató gépén marad a kép, a CSS és a JavaScript, tehát a második oldalletöltés lesz gyorsabb, nem az első. Fejléc-vezérelt: Cache-Control és ETag mondja meg, meddig őrizze meg a böngésző.
Ahol elromlik: ha hosszú lejáratot állítasz be, de a fájlnév nem változik verziózáskor. Ilyenkor a visszatérő látogató a régi stíluslapot használja, és számára eltört az oldal, miközben neked tökéletesen néz ki.
CDN-cache
A tartalomkiszolgáló hálózat földrajzilag közelebb viszi a fájlokat a látogatóhoz. Egy magyar közönségű, magyar szerveren futó oldalnál ez kisebb nyereség, mint amekkorát a marketinganyagok sugallnak. Ott számít igazán, ha külföldi látogatóid is vannak, vagy ha teljes oldalgyorsítást (full page CDN cache) is bekapcsolsz.
Ahol elromlik: dupla gyorsítótárazásnál. A CDN eltárolja a bővítményed által már eltárolt oldalt, és amikor te ürítesz a WordPressben, a CDN-en még hetekig ott marad a régi verzió.
Miért nem old meg a cache lassú adatbázist vagy túlterhelt sablont?
Rövid válasz: mert a cache nem gyorsítja fel a kódot, csak ritkábban futtatja le. Ha egy oldal legenerálása 3 másodperc, akkor a cache-elt kérések gyorsak lesznek, de minden egyes cache-hiány (új URL, lejárt bejegyzés, szűrő, keresés, bejelentkezett felhasználó) továbbra is 3 másodperc.
A gyakorlatban ez ott üt vissza, ahol a legfájóbb. Egy webshopnál a szűrőkombinációk gyakorlatilag végtelen sok URL-t adnak, ezeknek a többsége soha nem lesz cache-elt állapotban. Egy blogon a Google botja pont az új, még sosem kért URL-eket járja végig, tehát rendszeresen a lassú, generált változatot kapja. Egy tanácsadói oldalon az űrlapos oldalak eleve ki vannak zárva, tehát ott a látogató a nyers sebességet éli meg.
A tipikus okok, amiket a cache elrejt, de nem javít meg:
- Indexeletlen vagy felpuffadt adatbázistáblák, jellemzően a
wp_optionsautoload sorai és awp_postmeta. - Sablonok, amelyek oldalanként több száz lekérdezést futtatnak, mert minden elemhez külön kérdezik meg az adatbázist.
- Bővítmény-halmozás: 40 aktív bővítmény betöltése minden kérésnél megtörténik, cache-hiány esetén.
- Külső API-hívások a sablonban (árfolyam, időjárás, közösségi feed), amelyek időtúllépéskor másodperceket adnak a válaszidőhöz.
- Túlterhelt, osztott tárhely, ahol a szomszédok viszik el a processzoridőt.
Saját nézőpont és tapasztalat: a cache olyan, mint a fájdalomcsillapító. Attól, hogy nem érzed, a probléma megvan, és a legrosszabbkor jelentkezik: kampányindításkor, hírlevélküldés utáni forgalmi csúcsban, vagy amikor egy robot végigpásztázza az oldalt. Ezért javaslom mindig, hogy a szerver válaszidejét cache nélkül is mérd meg.
Hogyan mérd meg a valódi szerver-válaszidőt cache nélkül?
Rövid válasz: kérj le egy olyan URL-t, amit a cache biztosan nem tud kiszolgálni, és nézd meg a time to first byte értéket. Ha ez másodpercben mérhető, akkor nem cache-bővítményt kell választanod, hanem a szerverrel és a sablonnal kell foglalkozni.
A legegyszerűbb mérés parancssorból:
curl -o /dev/null -s -w "%{time_starttransfer}\n" https://pelda.hu/?nocache=1
A véletlenszerű paraméter miatt a legtöbb oldalcache kihagyja a kérést, tehát a generált oldal idejét méred. Futtasd le ötször, és a középső értéket vedd. Utána ugyanezt paraméter nélkül is, hogy lásd a cache-elt választ. A kettő különbsége mutatja meg, mekkora terhet visz el a cache, és mekkora marad a szerveren.
Szakmai feltételezés, nem szabvány: a gyakorlatban 800 ezredmásodperc alatti nem gyorsított TTFB-t szoktam egészségesnek tekinteni egy átlagos WordPress-oldalon, 1,5 másodperc felett pedig szerver- vagy kódszintű beavatkozást javaslok. Ez tapasztalati küszöb, nem hivatalos érték, és tartalomtípusonként eltérhet.
Kiegészítésnek érdemes a lekérdezés-számot is megnézni egy fejlesztői eszközzel (például a Query Monitor bővítménnyel), bekapcsolt cache mellett is, bejelentkezve. Ha egy egyszerű aloldal 300 lekérdezésből áll össze, ott a sablon a probléma, nem a gyorsítás hiánya.
Mit kell kizárni a gyorsítótárból?
Rövid válasz: mindent, ami felhasználónként más. Ha egy oldal tartalma attól függ, ki nézi, nem mehet közös oldalcache-be.
A kötelező kizárási lista:
- Kosár, pénztár, fiókoldal: WooCommerce esetén a
/kosar/,/penztar/,/fiokom/(és angol megfelelőik) mindig kizárva. - Bejelentkezett felhasználók: a legtöbb bővítmény alapból nem cache-el bejelentkezett munkamenetet, de ezt ellenőrizni kell, főleg tagsági vagy e-learning oldalnál.
- Űrlapos oldalak: ahol biztonsági token (nonce) vagy captcha van, a gyorsítótárazott token lejár, és az űrlap némán hibázik.
- Keresési találati oldalak és szűrt listák: ezek egyedi kombinációk, tárolásuk feleslegesen tölti meg a lemezt.
- API- és webhook-végpontok: a
/wp-json/alatti útvonalak és a fizetési szolgáltatók visszahívásai. - Munkamenet- és kosársütik: ha a kérésben ott van a
woocommerce_items_in_cartvagywordpress_logged_in_süti, a választ nem szabad közös tárból adni.
Hivatalosan igazolt: a WooCommerce dokumentációja kifejezetten kéri a kosár, a pénztár és a fiókoldal kizárását az oldalcache-ből. Ez nem vélemény, hanem a rendszer működési feltétele.
Hogyan ismered fel, hogy a cache elavult tartalmat szolgál ki?
Rövid válasz: ha te bejelentkezve mást látsz, mint egy privát böngészőablakban, szinte biztosan cache-problémád van, nem szerkesztési hibád.
A gyors diagnózis lépésről lépésre:
- Nyisd meg az oldalt privát ablakban. Ha ott a régi ár, régi nyitvatartás vagy régi szöveg jelenik meg, a cache régi példányt őriz.
- Hívd le ugyanazt az URL-t egy véletlen paraméterrel (
?v=123). Ha ott már a friss tartalom jön, ez megerősíti a diagnózist. - Nézd meg a válaszfejléceket:
curl -I https://pelda.hu/oldal/. Keresd azx-cache,cf-cache-status,ageéscache-controlsorokat. Azagemondja meg másodpercben, mennyi ideje ül a tárban az a példány. - Ha az
agenulla, de a tartalom mégis régi, akkor nem az oldalcache a bűnös, hanem az objektumcache vagy a CDN. - Ürítsd rétegenként, ne egyszerre: először a bővítmény oldalcache-ét, aztán a CDN-t, végül az objektumcache-t. Így megtudod, melyik réteg tartotta bent a régi verziót.
Az árulkodó jelek, amiket nem szabad félresöpörni: a mobilnézet más tartalmat mutat, mint az asztali; a látogatók régi akciót emlegetnek telefonon; a Search Console olyan címsort mutat a találatoknál, amit hetekkel korábban lecseréltél. Szakmai feltételezés: ez utóbbi esetben elképzelhető, hogy a kereső egy elavult, gyorsítótárazott változatot indexelt, de ezt csak élő lekéréssel lehet igazolni, mert a keresők saját újrafeldolgozási ütemterve is befolyásolja.
Milyen 7 pontos ellenőrzőlista alapján állítsd be a cache-t?
- Mérj előbb, gyorsíts utána. Rögzítsd a nem gyorsított TTFB-t és a lekérdezésszámot, mielőtt bármit bekapcsolsz. E nélkül nem fogod tudni, mit javított a bővítmény.
- Egy oldalcache legyen, ne három. Ha a tárhely szolgáltatója szerveroldali gyorsítást ad (LiteSpeed, Varnish, nginx fastcgi cache), ne tegyél mellé még egy PHP-alapú oldalcache-t. A dupla réteg kiszámíthatatlan ürítést eredményez.
- Állítsd be a kizárásokat az első napon. Kosár, pénztár, fiók, űrlapos oldalak, API-végpontok, süti alapú kizárás. Ne éles forgalomban derüljön ki, hogy hiányzott.
- Kapcsolj tartós objektumcache-t, ha van bejelentkezett forgalom. Webshopnál, tagsági oldalnál, foglalási rendszernél ez fontosabb, mint a page cache.
- Ellenőrizd az ürítési szabályokat. Bejegyzés mentésekor mi ürül: csak az adott oldal, vagy a kezdőlap, a kategória és a sitemap is? Ha csak az adott oldal, a listaoldalak elavulnak.
- Válaszd külön az egyesítést és a gyorsítást. A CSS- és JS-egyesítés, a késleltetett betöltés és a kritikus CSS nem cache, hanem optimalizálás. Egyesével kapcsold be őket, és minden lépés után nézd meg az oldalt, mert ezek törik el leggyakrabban a megjelenést.
- Mérj újra, és mérd a cache-hiányt is. A záró mérés ne csak a gyorsított állapotot mutassa. Az igazi kérdés az, hogy egy cache nélküli kérés mennyi idő alatt fut le, mert a robotok és az első látogatók azt kapják.
Milyen 3 tipikus hibajelenség fordul elő, és mi rájuk a megoldás?
1. A pénztár összeomlik, vagy más kosarát mutatja
Tünet: a vásárló üres kosarat lát, vagy idegen terméket talál benne, esetleg a fizetés előtt kidobja a rendszer. Ok: a kosárhoz kötött oldalak bekerültek a közös oldalcache-be, vagy a kosársüti nem szerepel a kizárási feltételek között. Megoldás: vedd fel a kosár, pénztár és fiókoldalt a kizárásokba, süti alapon is zárd ki a munkamenetet, és a CDN-en is állítsd be ugyanezeket a szabályokat. Utána tesztelj két különböző böngészőből, egyszerre.
2. Az űrlap némán nem küld el semmit
Tünet: a látogató kitölti a kapcsolatfelvételi űrlapot, rákattint a küldésre, és nem történik semmi, vagy általános hibaüzenetet kap. Ok: a gyorsítótárazott HTML-ben egy lejárt biztonsági token (nonce) van, amit a szerver visszautasít. Megoldás: zárd ki az űrlapos oldalakat az oldalcache-ből, vagy használd a bővítmény token-frissítő funkcióját, ha van ilyen. Saját tapasztalat: ez a leggyakrabban észrevétlen hiba, mert a tulajdonos bejelentkezve teszteli, ahol nincs cache, tehát nála mindig működik, miközben hetek óta nem érkezik érdeklődés.
3. A frissítés után eltört az oldal kinézete
Tünet: a visszatérő látogatóknál szétesik az elrendezés, az újaknál rendben van. Ok: a böngészőcache régi CSS- vagy JS-fájlt használ, mert a fájlnév vagy a verzióparaméter nem változott. Megoldás: verziózd a statikus fájlokat (a fájlnévben vagy lekérdezési paraméterben legyen verziószám), ürítsd a CDN-t is, és sablonfrissítés után mindig ellenőrizd az oldalt egy olyan böngészőben, amiben korábban már jártál. Ha a hiba a szerkesztőben is jelentkezik, gyanakodj OPcache-re, és indíttasd újra a PHP-t.
Hogyan függ össze mindez a keresőkkel és az AI-válaszmotorokkal?
Rövid válasz: a gyorsítás nem hozza a helyezést, de a lassúság és az elavult tartalom árthat. Egy jól beállított cache segítheti, hogy a robotok több oldalt tudjanak feldolgozni ugyanannyi idő alatt, egy rosszul beállított viszont régi vagy hiányos HTML-t adhat nekik.
Hivatalosan igazolt: a Google Search Central dokumentációja szerint az oldalélmény és a betöltési sebesség a rangsorolási jelek egyike, de nem felülíró tényező, és a jó sebesség önmagában nem garantál jobb helyezést. Szakmai feltételezés: az AI-válaszmotorok lekérő robotjai jellemzően szigorúbb időkorláttal dolgoznak, mint egy türelmes keresőrobot, ezért a lassú, nem gyorsított válasz nagyobb eséllyel marad kihagyva. Ez logikus következtetés a megfigyelt viselkedésből, nem publikált specifikáció.
A gyakorlati tanulság ugyanaz marad: a cache jó szolga, de rossz gazda. Akkor működik, ha egy egészséges rendszerre teszed rá. Ha viszont arra használod, hogy ne kelljen szembenézni a felpuffadt adatbázissal, a húsz felesleges bővítménnyel vagy a szűk tárhellyel, akkor csak elodázod a döntést, és a bajt olyan pillanatra időzíted, amikor a legdrágább.
Források és további olvasnivalók
- Google Search Central: Understanding page experience, Crawl budget management for large sites
- WordPress Developer Resources: Caching, Object Cache API, Transients API
- WooCommerce Documentation: Configuring caching plugins with WooCommerce
- PHP Manual: OPcache konfiguráció és beállítások
- MDN Web Docs: HTTP caching, Cache-Control fejléc
- W3C: Web Performance Working Group specifikációk
- web.dev: Core Web Vitals, Time to First Byte
- A cache nem gyorsítja fel a lassú kódot, csak ritkábban futtatja le, ezért a nem gyorsított első kérés marad az igazi mérőszám.
- Az öt gyorsítótár-réteg más problémát old meg, és külön-külön romlik el, ezért nem érdemes egyetlen kapcsolóként gondolni rájuk.
- Kosár, pénztár, fiókoldal, bejelentkezett felhasználó és űrlapos oldalak sosem mehetnek közös oldalcache-be.
- Az elavult tartalom felismerésének legolcsóbb módja a privát ablakos és a bejelentkezett nézet összevetése, plusz a válaszfejlécek átnézése.
- Mielőtt bővítményt választasz, mérd meg a TTFB-t gyorsítás nélkül: ha az másodpercben mérhető, a cache csak elrejti a bajt.
Gyakori kérdések
Elég egyetlen cache-bővítmény, vagy több kell egymás mellé?
Egy oldalcache-nek kell lennie, nem többnek. Ha a tárhelyed már ad szerveroldali gyorsítást (LiteSpeed, Varnish, nginx fastcgi cache), ne tegyél mellé PHP-alapú oldalcache-t, mert a két réteg egymástól függetlenül ürül, és kiszámíthatatlan lesz, mit lát a látogató. Objektumcache-t viszont nyugodtan használhatsz az oldalcache mellett, mert az más problémát old meg.
Miért lassú az oldalam akkor is, ha be van kapcsolva a cache?
Mert valószínűleg a cache-hiányos kéréseket méred. Új URL-nél, keresésnél, szűrésnél, bejelentkezett felhasználónál és a kizárt oldalakon a rendszer teljesen legenerálja az oldalt. Ha a generálás eleve lassú, azt a cache nem javítja meg. Mérd meg a válaszidőt egy véletlen paraméterrel ellátott URL-en, és ha ott is lassú, a szerverrel, az adatbázissal vagy a sablonnal kell foglalkozni.
Honnan tudom, hogy a látogató régi verziót lát-e?
Nyisd meg az oldalt privát böngészőablakban, és vesd össze azzal, amit bejelentkezve látsz. Ha eltér, nézd meg a válaszfejléceket a curl -I paranccsal: az age értéke megmondja, hány másodperce ül a tárban a példány, az x-cache vagy cf-cache-status pedig azt, hogy melyik réteg szolgálta ki. Ha az age nulla, de a tartalom mégis régi, akkor az objektumcache vagy a CDN őrzi.
A WooCommerce-nél mit kell mindenképpen kizárni?
A kosarat, a pénztárat és a fiókoldalt, valamint minden fizetési visszahívási végpontot. Ezenfelül süti alapon is érdemes kizárni a kérést, ha a látogatónak van kosártartalma vagy be van jelentkezve. Ugyanezeket a szabályokat a CDN-en is be kell állítani, különben a kizárás csak a szerveren érvényesül.
Javítja a cache a keresési helyezésemet?
Nem garantálja. A sebesség a rangsorolási jelek egyike, de önmagában nem emel előre. Amit reálisan várhatsz: a gyorsabb kiszolgálás segítheti a robotok hatékonyabb feldolgozását és javíthatja a látogatói élményt. Egy rosszul beállított cache viszont kifejezetten árthat, ha elavult vagy hiányos HTML-t ad vissza a keresőnek.
Objektumcache vagy oldalcache: melyikkel kezdjem?
Ha az oldalad döntően vendégforgalmat kap (bemutatkozó oldal, blog, szolgáltatói oldal), kezdd az oldalcache-sel, mert ott hozza a legnagyobb ugrást. Ha viszont sok a bejelentkezett felhasználó, kosár, foglalás vagy tanfolyami tartalom, a tartós objektumcache többet ér, mert az oldalcache azokon a felületeken eleve nem tud dolgozni.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.