WordPress cache: Redis, Varnish, LiteSpeed és OPcache – melyik mit gyorsít valójában?

A WordPress cache akkor gyorsít a legtöbbet, amikor pontosan tudod, melyik réteg válaszol a kérésre. Ha a Varnish régi HTML-választ ad, a Redis elavult objektumot tart, az OPcache pedig a PHP-futtatást gyorsítja, a „töröld a cache-t” már nem hibakeresési stratégia, csak találgatás.

Egy 50 termékes WooCommerce-webshopnál más feladat a publikus termékoldal gyors kiszolgálása, mint a kosár, a pénztár vagy a belépett ügyfél adatainak kezelése. Az elsőhöz teljes oldalas cache kell, a másodikhoz felhasználónként változó adatok és pontos kizárási szabályok tartoznak.

Ebben a cikkben végigmegyünk a kérés útvonalán, elmagyarázzuk, mi a Redis, a Varnish, a LiteSpeed és az OPcache, és megmutatjuk, miért a LiteSpeed Cache a legkényelmesebb teljes oldalas megoldás WordPresshez.

Hol helyezkedik el a WordPress cache a kérés útvonalán?

A WordPress cache több, egymásra épülő réteg gyűjtőneve. Mindegyik a kérés útvonalának más pontján tárol újra felhasználható adatot vagy kész választ, hogy a következő látogatónál ne kelljen ugyanazt a munkát elvégezni.

Egyszerűsítve a kérés útvonala így néz ki:

böngésző→CDN→webszerver vagy reverse proxy→teljes oldalas cache→PHP és OPcache→WordPress→objektum cache (pl. Redis) és adatbázis→HTML-válasz

Egy étterem hasonlata segít eligazodni a rétegek között:

• Böngészőcache: a vendég hazaviszi a desszertet, legközelebb nem kell érte visszajönnie. A böngésző a képeket, CSS- és JS-fájlokat a saját gépén tárolja.
• CDN: fiókkonyhák a város több pontján, hogy a vendégnek ne kelljen a központig utaznia. A statikus fájlok a látogatóhoz legközelebbi szerverről érkeznek.
• Teljes oldalas cache (Varnish vagy LiteSpeed Cache): kész tálak a pultban. Ha valaki ugyanazt kéri, azonnal megkapja, a konyhán senki nem mozdul.
• OPcache: a szakács fejből tudja a receptet, nem kell minden rendelésnél újraolvasnia a szakácskönyvet.
• Redis: előkészített hozzávalók a pult alatt. Ha mégis főzni kell, a felvágott zöldség már ott van, nem kell a raktárig (az adatbázisig) elmenni érte.

Minél korábban válaszol egy réteg a kérésre, annál kevesebb munka marad a szerverre. A teljes oldalas cache ezért a legnagyobb gyorsító: ha talál kész választ, a kérés el sem jut a PHP-ig.

Mi az OPcache, a Redis, a Varnish és a LiteSpeed?

A négy technológia négy különböző problémát old meg. Az OPcache a PHP-kód futtatását, a Redis az adatbázis-lekéréseket, a Varnish és a LiteSpeed Cache pedig a teljes HTML-oldal kiszolgálását gyorsítja.

OPcache: gyorsabb PHP-futtatás

Az OPcache a PHP beépített gyorsítója. A WordPress minden kérésnél több száz PHP-fájlt tölt be (magot, bővítményeket, sablont), és ezeket a szervernek gépi utasításokká kell alakítania. Az OPcache ezt az átalakított változatot memóriában tartja, így a következő kérésnél kimarad a fordítás.

Az OPcache a legtöbb PHP-környezetben alapból be van kapcsolva, és szinte soha nem okoz látható hibát. Nem helyettesíti a teljes oldalas cache-t, és nem csökkenti az adatbázis-lekérdezések számát: a WordPress továbbra is minden kérésnél lefut, csak gyorsabban indul.

Redis: gyorsabb adatbázis-lekérés

A Redis egy memóriában futó adattár, amelyet WordPressnél objektum cache-ként használnak. A WordPress rengeteg adatot kér le újra és újra az adatbázisból: beállításokat, menüket, termékadatokat, lekérdezési eredményeket. A Redis ezeket memóriában tartja, így nem kell minden alkalommal az adatbázishoz fordulni.

A Redis ott hasznos igazán, ahol a teljes oldalas cache nem segít: a kosárban, a pénztárban, a belépett felhasználók felületén és az adminban. Kész HTML-oldalt viszont nem tárol, ezért önmagában nem helyettesíti a teljes oldalas cache-t.

Varnish: teljes oldalas cache külön proxyként

A Varnish egy külön szoftver, amely a webszerver elé ül, és a kész HTML-válaszokat tárolja. Ha egy anonim látogató olyan oldalt kér, amely már a Varnish tárában van, a válasz PHP-futtatás nélkül megy ki.

A Varnish nagy forgalmú, egyedi környezetekben bizonyított, de WordPresshez sok kézi munkát igényel. A szabályait külön konfigurációs nyelven (VCL) kell megírni, a cookie-kezelést és a kizárásokat magadnak kell beállítanod, a törléshez külön bővítmény kell, és a HTTPS-forgalmat sem kezeli közvetlenül, ezért elé még egy réteg kerül.

LiteSpeed és LiteSpeed Cache: teljes oldalas cache a webszerverbe építve

A LiteSpeed egy webszerver, az Apache gyorsabb, vele kompatibilis alternatívája: ugyanúgy olvassa a .htaccess fájlokat, így a WordPress-oldalak módosítás nélkül futnak rajta. A LiteSpeed Cache (LSCache) a webszerverbe épített teljes oldalas cache, amelyet az ingyenes LiteSpeed Cache WordPress-bővítmény vezérel.

A különbség a Varnishhoz képest az, hogy nincs külön réteg: a cache maga a webszerver része, a bővítmény pedig a WordPressből pontosan megmondja neki, mit tároljon és mikor ürítse.

Miért erősebb a LiteSpeed Cache a Varnishnál WordPressen?

A LiteSpeed Cache azért kényelmesebb WordPresshez, mert ismeri a WordPress működését. A Varnish csak HTTP-kéréseket és -válaszokat lát, a LiteSpeed Cache bővítménye viszont tudja, melyik bejegyzés, kategória vagy termék változott.

• Automatikus, célzott ürítés: ha módosítasz egy bejegyzést, az LSCache csak az érintett oldalakat üríti (a bejegyzést, a kategóriáját, a főoldalt), a cache többi része érintetlen marad.
• Nincs extra réteg: nem kell külön proxyt, VCL-szabályokat és HTTPS-kezelést karbantartani. Eggyel kevesebb hely, ahol régi tartalom ragadhat be.
• Bejelentkezett felhasználók kezelése: az LSCache külön privát cache-t tud kezelni a belépett felhasználóknak, és az ESI (Edge Side Includes) segítségével egy oldal személyre szabott részeit külön kezelheti a közös részektől.
• WooCommerce-támogatás: a kosarat, a pénztárt és a fiókoldalt alapból kihagyja a közös cache-ből, így ezeket nem kell kézzel kizárnod.
• Egy bővítmény, több feladat: a LiteSpeed Cache bővítményből a böngészőcache, a CSS- és JS-optimalizálás és az objektum cache (Redis vagy Memcached) is beállítható.

A Varnish ott marad erős választás, ahol egyedi, nagy forgalmú infrastruktúra fut, és van csapat, aki karbantartja a szabályait. Egy ügynökségnek, amely több WordPress-oldalt kezel, a LiteSpeed Cache kevesebb munkával ad hasonló vagy jobb eredményt.

💡 Többet akarsz tudni a LiteSpeed Cache beállításairól? Nézd meg részletes útmutatóinkat: LiteSpeed Cache – Sybell Tudásbázis

Melyik cache-réteget hol kapcsold be WordPressben?

Anonim, minden látogatónak azonos oldalakon egyetlen teljes oldalas cache legyen aktív. Mellette az OPcache a PHP-futtatást, az objektum cache pedig az ismétlődő adatlekéréseket gyorsíthatja. A személyre szabott állapotoknál – belépett felhasználóknál és a webshop kosaránál – viszont külön szabályok kellenek.

Mi változik bejelentkezett felhasználóknál?

A teljes oldalas cache nem adhatja vissza egy belépett felhasználó személyre szabott oldalát egy másik látogatónak. A wordpress_logged_in_ cookie-t, az admin- és profiloldalakat, valamint az egyedi nonce-okat kezelő kéréseket a közös cache-nek ki kell zárnia, vagy a Vary fejléccel külön kell kezelnie.

Bejelentkezett állapotban az OPcache és a Redis továbbra is gyorsítja a PHP-kódot és az adatlekéréseket. A LiteSpeed Cache privát cache-e és ESI-támogatása pedig azt is lehetővé teszi, hogy a belépett felhasználók oldalainak közös részei is gyorsítótárból érkezzenek.

Mi változik WooCommerce-kosárnál és checkoutnál?

A kosár, a pénztár és a fiókoldal állapota felhasználónként változik, ezért ezeket a teljes oldalas cache-ből ki kell zárni. A WooCommerce tipikus cookie-jai közé tartozik a woocommerce_items_in_cart és a wp_woocommerce_session_, de a tényleges kizárási szabályokat mindig az adott webshophoz kell igazítani.

A termékoldal, a kategóriaoldal és a keresési eredmény cache-elhető, a kosár és a checkout viszont munkamenetfüggő. Hibás szabály esetén a látogató régi árat vagy készletet lát, üres kosarat kap, vagy a checkout ellenőrzése nem egyezik. A LiteSpeed Cache ezeket az oldalakat alapból kihagyja, de egyedi bővítményeknél (pl. kívánságlista, egyedi árazás) érdemes anonim, belépett és kosaras állapotban is tesztelni.

Hogyan kerüld el a több teljes oldalas cache ütközését?

Teljes oldalas cache-ből egy legyen. Ha a Varnish és a LiteSpeed Cache egyszerre tárol HTML-t, mindkettő a saját szabályai szerint üríti, és könnyen maradhat régi oldal valamelyikben. LiteSpeed webszerveren a Varnishra nincs szükség, mert a teljes oldalas cache már a webszerver része.

Ugyanez érvényes a teljes oldalas cache-t is tartalmazó bővítményekre: a LiteSpeed Cache mellett ne fusson WP Rocket, W3 Total Cache vagy WP Super Cache oldal-cache funkciója.

💡 Ha a cache-beállítások rendszeres ellenőrzése nem fér bele az ügynökségi workflow-ba, a WordPress-karbantartási szolgáltatásunk ezt is leveszi a válladról. WordPress és WooCommerce karbantartás

Hogyan építs fel megbízható WordPress cache-ürítési stratégiát?

Mindig azt a réteget ürítsd, amelyik a régi választ vagy adatot tartja. A globális cache-törlés gyorsnak tűnik, de elfedi, melyik szabály hiányzik, és hideg cache-ből újra fel kell építeni az egész oldalt.

A megbízható folyamat öt lépésből áll:

1. Azonosítsd a régi választ reprodukcióval és a válaszfejlécek ellenőrzésével.
2. Ürítsd a legszűkebb érintett réteget: egy oldalt, egy terméket, egy objektumot.
3. Töröld a függő oldalakat is, ha a változás listázó- vagy archívumoldalak tartalmát érinti.
4. Teszteld külön az anonim, a belépett és a kosaras útvonalat.
5. Dokumentáld, mely esemény (deploy, ármódosítás, tartalomfrissítés) indít ürítést.

A LiteSpeed Cache a 2. és 3. lépés nagy részét automatikusan elvégzi: a bővítmény tudja, mely oldalak tartoznak egy módosított bejegyzéshez vagy termékhez, és csak azokat üríti.

Az ellenőrzésnél az X-LiteSpeed-Cache fejléc mutatja meg, hogy az oldal a LiteSpeed Cache-ből érkezett-e (hit) vagy frissen készült (miss). Más környezetben az X-Cache, az Age vagy a Via fejléc ad hasonló információt. Egyetlen fejlécből ne vonj le következtetést: hasonlítsd össze a hideg és a bemelegített kérést, valamint a tartalom tényleges állapotát.

Nagyobb költözésnél a tárhely költöztetés folyamatát is érdemes úgy megtervezni, hogy a cache-beállítások, a DNS-átállás és az első bemelegítés külön ellenőrzési pont legyen.

Összegzés

Az OPcache a PHP-futtatást, a Redis az adatlekéréseket, a Varnish és a LiteSpeed Cache pedig a teljes HTML-oldal kiszolgálását gyorsítja. A jól beállított WordPress cache nem attól működik, hogy minden réteget bekapcsolsz, hanem attól, hogy mindegyiknek egyértelmű feladata van. LiteSpeed webszerveren ehhez a legkevesebb réteg kell: a teljes oldalas cache a szerver része, a WordPress-bővítmény pedig automatikusan, célzottan üríti.

A Sybell Hostingnál tárhelyeink LiteSpeed webszerveren futnak, így az ingyenes LiteSpeed Cache bővítménnyel külön proxy és bonyolult szabályok nélkül kapsz szerverszintű teljes oldalas cache-t. Ha gyorsabb WordPress-oldalt szeretnél kevesebb beállítással, nézd meg tárhelycsomagjainkat.