Tárhely és teljesítmény
Hogyan tesszük gyorssá a WordPress-t: LiteSpeed Enterprise, LSCache és webhelyenkénti Redis
A leggyorsabb WordPress-kérés az, amelyik soha nem fut le — íme, hogyan válaszolja meg rendszerünk a legtöbb látogatást a gyorsítótárból, még mielőtt a PHP vagy a MySQL egyáltalán meghívásra kerülne, és mit jelent mindez a Core Web Vitals szempontjából.
A leggyorsabb kérés az, amely soha nem fut le
Egy szabványos WordPress-kérés erőforrás-igényes. A webszerver átadja a feladatot a PHP-nak, a PHP elindítja a WordPress rendszert, futtatja a bővítményeket, több tucatszor lekérdezi a MySQL-t, összeállítja a HTML-t, és csak ezután küldi vissza a bájtokat. Egy forgalmas webhelyen ez az egész folyamat minden egyes látogató esetében lezajlik, és szinte az összes első bájtig eltelt idő itt vész el.
A mi válaszunk az, hogy biztosítjuk: a legtöbb látogatás alkalmával ebből semmi se történjen meg. Az általunk hosztolt webhelyeken – több mint 100 000 PBN-oldalon, valamint a fősodorbeli kezelt WordPress-oldalakon – a front-end oldalmegtekintések döntő többségét előre renderelt, teljes oldalként, közvetlenül a gyorsítótárból szolgáljuk ki, a PHP meghívása vagy az adatbázis érintése nélkül. A bejegyzés további része arról szól, hogyan illeszkednek egymáshoz az ezt lehetővé tevő rétegek, és hol nyeri el mindegyik a maga helyét.
A legfontosabb szempont, hogy ezek nem egymással versengő gyorsítótárak, amelyek közül választania kellene. A teljes oldalas gyorsítótár, az objektum-gyorsítótár és a CDN-végpont mindegyike más típusú kérést kezel, a valódi értékük pedig abban rejlik, ahogyan egymásnak átadják a feladatokat.
LiteSpeed Enterprise + LSCache: a teljes oldalas réteg
Minden webhely LiteSpeed Enterprise rendszeren fut, szerverszintű LSCache gyorsítótárazással. Ha a frontend válasza gyorsítótárazható, a webszerver LiteSpeed cache-control és tag fejlécekkel látja el, és a LiteSpeed közvetlenül a teljes oldalt szolgálja ki a következő lekéréskor — nem indul el PHP-folyamat, és nem fut le MySQL-lekérdezés. Ez az egyetlen legnagyobb tényező a WordPress TTFB optimalizálásában, mivel a teljes alkalmazásbetöltést kiiktatja a kritikus útvonalból.
Mivel az LSCache nem egy PHP-bővítményben, hanem a webszerveren belül működik, a kérések életciklusában korábban kezd el dolgozni, és olyan formában tárolja az oldalakat, amelyet a szerver azonnal ki tud üríteni. Egy gyorsítótár-bejáró folyamatosan előtöltve tartja a népszerű oldalakat, így a kiürítés utáni első látogatónak nem kell megfizetnie az oldal újragenerálásának árát. Az eredmény egy érezhetően alacsonyabb és kiegyensúlyozottabb TTFB egy olyan, általános környezetre ráerőltetett, kizárólag bővítményalapú gyorsítótárhoz képest, ahol a gyorsítótár továbbra is a PHP mögött helyezkedik el.
A saját, tárolószintű gyorsítótár-bővítményünk előre telepítve és automatikusan frissítve érkezik minden webhelyre, és a kezdetektől megfelelően összekapcsolja a WordPress rendszert az LSCache megoldással. Egy nem LiteSpeed forráson egyszerűen nem bocsát ki teljes oldalas fejléceket, és félreáll az útból, miközben az objektum-gyorsítótár és a kizárási szabályok továbbra is ellátják feladatukat — így az átköltöztetett webhely soha nem marad hibás, félig konfigurált állapotban.
Gyorsnak maradni elavult tartalom kiszolgálása nélkül: ESI és intelligens automatikus ürítés
Az agresszív teljes oldalas gyorsítótárazásnak két klasszikus hibalehetősége van: egy bejelentkezett felhasználónak egy másik személy oldalának kiszolgálása, valamint olyan oldal kiszolgálása bárkinek, amelynek meg kellett volna változnia. Mindkettőt a gyorsítótárazási rétegnél oldják meg, nem pedig a kevesebb gyorsítótárazással.
Az ESI (Edge Side Includes) lehetővé teszi számunkra az oldal gyorsítótárazását, miközben kivételeket képez azon részek számára, amelyeknek dinamikusnak kell maradniuk. Egy WooCommerce áruházban a katalógus-, termék- és kategóriaoldalak teljes oldalas gyorsítótárból kerülnek kiszolgálásra a lehető leggyorsabb TTFB érdekében, miközben az ESI kérésenként jeleníti meg a kosárrészletet, a mini kosár összegzését és a fiókállapotot. A kosár, a pénztár, a fiókom, valamint a nonce- vagy munkamenet-oldalak alapértelmezés szerint ki vannak zárva. A vásárlók mindig a saját kosarukat és egy működő pénztárat látnak; a kirakatot pedig mindenki továbbra is a gyorsítótárból kapja.
A frissességet intelligens automatikus ürítés biztosítja. Az ürítési horgok (purge hooks) automatikusan aktiválódnak, ha a tartalom, a termékek, az árak vagy a rendelések módosulnak, így az érintett gyorsítótárazott oldalak azonnal frissülnek, nem pedig egy időzítő alapján, emellett igény szerint is üríthet a vezérlőpultról vagy a WordPress felületéről. A címkealapú ürítés azt jelenti, hogy egy bejegyzés szerkesztése csak az adott bejegyzést és annak archívumait törli – nem a teljes gyorsítótárat –, így egyetlen szerkesztés miatt nem indul hidegen az egész webhely.
Webhelyenkénti Redis objektum-gyorsítótár: annak, ami nem lehet teljes oldal
Nem minden kérés lehet statikus teljes oldal. A bejelentkezett munkameneteknek, a WordPress adminisztrációs felületének, a WooCommerce kosaraknak, a keresésnek és az ESI által élve hagyott dinamikus töredékeknek mind PHP-t kell futtatniuk. Ezeknél a cél az „alkalmazás kihagyásáról” az „adatbázis kihagyására” helyeződik át.
Minden webhely saját dedikált Redis objektum-gyorsítótárat kap. A WordPress a memóriában gyorsítótárazza az ismétlődő adatbázis-olvasások eredményeit — beállításokat, átmeneti adatokat (transients), bejegyzés- és kifejezés-kereséseket, valamint WooCommerce termék- és munkamenet-adatokat —, így nem fut le ugyanaz a lekérdezés a MySQL-ben minden egyes lekérésnél. A hatás pontosan ott a legszembetűnőbb, ahol a teljes oldalas gyorsítótár nem tud segíteni: gyorsabb vezérlőpultok, gyorsabb kosarak és lényegesen kisebb adatbázis-terhelés nagy forgalom esetén.
Az objektum-gyorsítótár webhelyenként elkülönített, nem megosztott, ami mind a teljesítmény, mind az izoláció szempontjából lényeges. A webhelyenkénti adatbázis-szabályozással kombinálva egyetlen webhely nagy terhelést jelentő vagy rosszul megírt lekérdezései sem vonhatják el az adatbázis-erőforrásokat a szomszédos webhelyektől. A gyorsítótárazási funkciókat ismertető oldalunkon bővebben is olvashat arról, hogyan működik együtt a teljes többrétegű rendszer, az izoláció alatt pedig a bérlők közötti elhatárolásokról tájékozódhat.
Az edge és a mögöttes szállítás
Az eredeti kiszolgálón (origin) található gyorsítótárnak továbbra is át kell haladnia a hálózaton. A szerver előtt a CDN edge helyezkedik el, így a statikus elemek és a gyorsítótárazható oldalak a látogatóhoz közeli jelenléti pontról (PoP) kerülnek kiszolgálásra, az eredeti szerver pedig még terhelés alatt is csendes marad. A footprint-mentes tárhely-szolgáltatásunk esetében ugyanez az edge egy több CDN-szolgáltatóra kiterjedő multi-CDN pool, amely a SEO-lábnyom csökkentését és a teljesítmény növelését egyaránt szolgálja; a hagyományos WordPress esetén pedig egyszerűen egy gyors, jól működő réteg, amely tétlenül tartja az eredeti kiszolgálókat.
A háttérben nem spóroltunk az alapokon. A webhelyek NVMe tárhelyen futnak HTTP/3 protokollal, így a gyorsítótár által küldött bájtok modern, multiplexelt átvitelen keresztül érkeznek, és minden gyorsítótár-tévesztés (cache miss) mögött gyors tárhely áll. Ezen rétegek egyike sem fizetős kiegészítő: a LiteSpeed, az LSCache, az oldalankénti Redis, az NVMe és a HTTP/3 minden csomag alapfelszereltségét képezik, nem pedig feláras szintek.
Mi az, ami valóban javítja a Core Web Vitals mutatóit
Érdemes pontosnak lenni, mert a tárhelyszolgáltatást gyakran túlértékelik a Core Web Vitals tekintetében. A TTFB az egyenlet azon része, amelyért a szerver felel, és a fent említett gyorsítótárazási verem az, ami csökkenti azt — az edge hálózatról HTTP/3 protokollon keresztül kiszolgált, teljes gyorsítótárazott oldal körülbelül a legalacsonyabb elérhető TTFB-értéket képviseli. Mivel a TTFB a Largest Contentful Paint kiindulópontja, a gyors forráskiszolgáló olyan előnyt biztosít minden további mérőszámnak, amelyet egyébként nem kaphatna meg.
Az LCP, a CLS és az INP mutatók azonban leginkább a böngészőben, maga az oldal által dőlnek el: egy nem optimalizált kiemelt kép (hero image), a renderelést blokkoló CSS és JavaScript, a betűtípusok és hirdetések betöltődésekor elcsúszó elrendezés, valamint a bővítmények által okozott, fő szálat (main-thread) terhelő nehéz feladatok miatt. Semmilyen mértékű szerveroldali gyorsítótárazás nem javít meg egy 2 MB-os kiemelt képet vagy egy olyan témát, amely megabájtokban mérhető JavaScriptet tölt be. A tisztességes tárhelyszolgáltatás gyakorlatilag elhanyagolhatóvá és egyenletessé teszi a szerver hozzájárulását, ezt követően pedig a webhely feladata, hogy a frontend letisztult és gyors maradjon.
Ez a munkamegosztás jelenti a hasznos mentális modellt. Garantáljuk, hogy a kérés gyorsan eléri a böngészőt, és nagy forgalom mellett is gyors marad; Ön gondoskodik arról, hogy az adatcsomag kicsi és stabil maradjon. Ahol a kettő találkozik — a gyorsítótár előzetes feltöltése (cache warm-up), a hálózat peremén történő kiszolgálás (edge delivery), valamint az adatbázis válaszkészségének fenntartása a dinamikus oldalak megtorpanásának elkerülése érdekében —, ott van a technológiai környezetünk pontosan behangolva, és ez teszi a felügyelt WordPress rendszert ezen a platformon gyorsabbá, mint amilyen ugyanez a webhely lenne egy általános tárhelyen.
Gyakran ismételt kérdések
Szükségem van még gyorsítótárazó bővítményre, mint például a WP Rocket?
Nem. A teljes oldalas gyorsítótárazást a webszerveren a LiteSpeed LSCache modulja kezeli, a saját — előre telepített és automatikusan frissülő — gyorsítótárazó bővítményünk pedig megfelelően összekapcsolja vele a WordPress rendszert, a háttérben webhelyenkénti Redis objektum-gyorsítótárral. Egy második teljes oldalas gyorsítótárazó bővítmény hozzáadása segítség helyett általában ütközik a szerverszintű gyorsítótárral, így nem szükséges és nem ajánlott.
A gyorsítótárazás tönkreteheti a WooCommerce kosaramat vagy a bejelentkezett felhasználók oldalait?
Nem. A kosár, a pénztár, a my-account, valamint a nonce- vagy munkamenet-oldalak alapértelmezés szerint ki vannak zárva a gyorsítótárból, az ESI pedig élőben tartja a kosártöredéket és az összegeket az egyébként gyorsítótárazott oldalakon. A vásárlók mindig a saját kosarukat és a működő pénztárt látják, miközben a kirakat továbbra is a gyorsítótárból töltődik be.
Hogyan marad friss a gyorsítótár, amikor közzéteszek vagy szerkesztek?
Az intelligens automatikus ürítés a releváns WordPress horgokon aktiválódik, így a közzététel, a tartalom szerkesztése vagy a termék, ár vagy rendelés módosítása csak az érintett oldalakat és azok archívumait törli – nem a teljes gyorsítótárat –, egy bejáró pedig újra előtölti őket. Igény szerint a vezérlőpultról vagy közvetlenül a WordPress felületéről is elvégezheti az ürítést.
Biztosíthat önmagában a tárhely tökéletes Core Web Vitals értékeket?
Ez a lehető legjobb TTFB-t biztosítja Önnek, ami a szerver része, és előnyt jelent a Largest Contentful Paint számára. De az LCP-t, a CLS-t és az INP-t nagyrészt maga az oldal határozza meg — a képméretek, a renderelést blokkoló erőforrások, az elrendezés stabilitása és a fő szálon futó JavaScript. A technológiai stackünk gyorssá és következetessé teszi a szerver hozzájárulását; a front-end adatforgalom alacsonyan tartása az, ami megszünteti a fennmaradó különbséget.
Kapcsolódó
Próbálja ki ingyenesen 14 napig
Indítsa el első webhelyeit 14 napig ingyenesen — bankkártya nélkül. Meglévő hálózatot költöztet? Az átköltöztetés korlátlanul ingyenes.
Kezdés ingyen