Tárhely és teljesítmény
Így tesszük gyorsabbá a WordPress webhelyeket: LiteSpeed Enterprise, LSCache és webhelyenkénti Redis
A leggyorsabb WordPress kérés az, amelyik el sem fut – így szolgálja ki vermünkből a látogatások nagy részét a stackünk még azelőtt, hogy a PHP vagy a MySQL egyáltalán elindulna, és ezt jelentik ezek a Core Web Vitals mutatók számára.
A leggyorsabb kérés az, amelyik meg sem fut
Egy szabványos WordPress kérés költséges. A webszerver átadja a folyamatot a PHP-nak, a PHP elindítja a WordPress-t, futtatja a bővítményeket,néhány 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ónál lezajlik, és szinte az összes első bájtok megérkezéséig eltelt idő (time-to-first-byte) itt megy el.
A mi válaszunk az, hogy gondoskodunk arról, hogy a látogatások túlnyomó többségében ebből semmi se történjen meg. Az általunk hostolt webhelyeken – több mint 100 000 PBN webhelyen, valamint a főbb menedzselt WordPress oldalakon – a front-end oldalmegtekintések nagy többségét előre renderelt, teljes oldalként szolgáljuk ki közvetlenül a gyorsítótárból, anélkül, hogy a PHP-t meghívnánk vagy hozzáérnénk az adatbázishoz. A bejegyzés további része arról szól, hogy az ezt biztosító rétegek hogyan illeszkednek össze, és az egyes rétegek hol érdemlik ki a helyüket.
A lényeges szemléletmód az, hogy ezek nem egymással versengő gyorsítótárak, amelyek közül választani kell. A teljes oldalas gyorsítótár, az objektum-gyorsítótár és a CDN peremhálózata mind egy-egy eltérő kéréstípust szolgálnak ki, és az értékük abban rejlik, ahogyan egymásnak átadják a feladatot.
LiteSpeed Enterprise + LSCache: a teljes oldalas réteg
Minden webhely a LiteSpeed Enterprise rendszeren fut, kiszolgálószintű LSCache gyorsítótárral. Ha egy előlapi válasz gyorsítótárazható, a webszerver LiteSpeed cache-control és címke fejlécekkel látja el, és a következő kérésnél a LiteSpeed közvetlenül a teljes oldalt szolgálja ki – nincs elindított PHP folyamat, nincs lefuttatott MySQL lekérdezés. Ez a WordPress TTFB legnagyobb tényezője, mivel eltávolítja a teljes alkalmazásbetöltést a kritikus útvonalról.
Mivel az LSCache közvetlenül a webszerverben működik, nem pedig egy PHP-bővítményben, a kérés életciklusának egy korábbi szakaszában kezd el dolgozni, és olyan formában tartja meg az oldalakat, amelyet a szerver azonnal ki tud szolgálni. Egy gyorsítótár-bejáró melegen tartja a népszerű oldalakat, így a törlés utáni első látogatónak nem kell megfizetnie az oldal újragenerálásának idejét. Ennek eredményeként a TTFB észrevehetően alacsonyabb és egyenletesebb, mint egy általános veremre ráépített, tisztán bővítményalapú gyorsítótár esetében, ahol a gyorsítótár továbbra is a PHP mögött helyezkedik el.
A saját fejlesztésű, repo-szintű gyorsítótár-bővítményünk minden webhelyen előre telepítve és automatikusan frissítve érkezik, és a WordPress rendszert már a dobozból kivéve helyesen köti össze a LSCache-dzsel. Egy nem LiteSpeed alapú forráskiszolgálón egyszerűen nem bocsát ki teljes oldalas fejléceket, és félreáll, miközben az objektum-gyorsítótár és a kivételi szabályok továbbra is végzik a dolgukat – így az áttelepített webhely soha nem marad törött, félig konfigurált állapotban.
Gyorsnak maradni elévült tartalom nélkül: ESI és intelligens automatikus törlés
Az agresszív teljes oldalas gyorsítótárazásnak két klasszikus hibalehetősége van: bejelentkezett felhasználónak más oldalát kiszolgálni, és bárkinek olyan oldalt kiszolgálni, amelynek meg kellett volna változnia. Mindkettőt a gyorsítótárazási rétegben oldják meg, nem pedig a ritkább gyorsítótárazással.
Az ESI (Edge Side Includes) segítségével gyorsítótárazhatjuk az oldalt, miközben réseket hagyunk az élőben maradó részeknek. Egy WooCommerce áruházban a katalógus-, termék- és kategóriaoldalak teljes oldalas gyorsítótárként szolgálnak a lehető leggyorsabb TTFB érdekében, míg az ESI kérésenként rendereli a kosártöredéket, a minikosár összegeit és a fiók állapotát. A kosár, a pénztár, a fiókom és bármilyen nonce- vagy munkamenet-oldal alapértelmezés szerint ki van zárva. A vásárlók mindig a saját kosarukat és egy működő pénztárat látnak; mindenki más pedig a gyorsítótárból kapja a boltot.
A frissességről az intelligens automatikus ürítés gondoskodik. Az ürítési hívások automatikusan lefutnak, amikor a tartalom, a termékek, az árak vagy a rendelések megváltoznak, így a releváns gyorsítótárazott oldalak azonnal frissülnek az időzítés helyett, és a vezérlőpultról vagy a WordPress belülről is kezdeményezhet ürítést igény szerint. A címkealapú ürítés azt jelenti, hogy egy bejegyzés szerkesztése az adott bejegyzést és az archívumait törli – nem a teljes gyorsítótárat –, így egyetlen szerkesztés miatt sem kell a teljes webhelyet újraindítani.
Webhelyenkénti Redis objektumgyorsítótár: amihez nem elég egy teljes oldal
Nem minden kérés lehet egy statikus teljes oldal. A bejelentkezett munkameneteknek, a WordPress adminfelületnek, a WooCommerce kosaraknak, a keresésnek és az ESI által életben hagyott dinamikus töredékeknek mind PHP-n kell futniuk. Ezeknél a cél az „alkalmazás kihagyásáról” az „adatbázis kihagyására” módosul.
Minden webhely saját, dedikált Redis objektumgyorsítótárat kap. A WordPress a memóriában tárolja az ismételt adatbázis-olvasások eredményeit – a beállításokat, az ideiglenes elemeket, a bejegyzés- és kifejezéslekérdezéseket, a WooCommerce termék- és munkamenet-adatait –, így ugyanazt a lekérdezést nem kell minden egyes találatkor futtatni a MySQL-en. 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 nagyságrenddel alacsonyabb adatbázis-terhelés forgalom idején.
Az objektum-gyorsítótár oldalszinten működik, nem megosztott, ami mind a teljesítmény, mind az izoláció szempontjából fontos. Az oldalszintű adatbázis-fojtással kombinálva egy-egy oldal nehéz vagy rosszul megírt lekérdezései nem tudják elvonni az erőforrásokat a szomszédos oldalakat kiszolgáló adatbázistól. További részleteket olvashat arról, hogy a többrétegű beállítás egyes elemei hogyan kapcsolódnak egymáshoz a gyorsítótárazási funkció oldalunkon, a bérlők közötti határokról pedig az izolációs oldalon talál információkat.
A peremhálózat és az alatta lévő átvitel
Az eredeteten élő gyorsítótárnak még át kell utaznia a hálózaton. A kiszolgáló előtt kap helyet a CDN peremhálózata, így a statikus elemeket és a gyorsítótárazható oldalakat a látogatóhoz közeli jelenléti pontról szolgáljuk ki, és a forráskiszolgáló terhelés alatt is csendes marad. A footprint-mentes tárhelytermékcsaládunk esetében ugyanez a peremhálózat több szolgáltató között megosztott multi-CDN készlet, amely a teljesítménycél mellett egy keresőoptimalizálási célt is szolgál; a mainstream WordPress esetében ez egyszerűen egy gyors, jól működő réteg, amely tétlenül tartja a forráskiszolgálókat.
A felszín alatt az alapokon sincs spórolva. A webhelyek NVMe tárolón futnak HTTP/3-mal, így a gyorsítótár által küldött bájtok egy modern, multiplexelt transzporton keresztül érkeznek meg, és minden gyorsítótár-találat elmaradása mögött is gyors tároló áll. E rétegek egyike sem kiegészítő: a LiteSpeed, az LSCache, a webhelyenkénti Redis, az NVMe és a HTTP/3 minden csomagnak az alapfelszereltsége, nem pedig egy feláras szint.
Mi mozgatja valójában a Core Web Vitals mutatókat
Érdemes pontosnak lenni, mert a tárhelyszolgáltatásokat gyakran a Core Web Vitals terén túlértékesítik. A TTFB az egyenlet azon része, amelyért a szerver felel, és a felette lévő gyorsítótár-réteg az, ami lecsökkenti azt – egy peremhálózatról (edge) HTTP/3-on keresztül kiszolgált, gyorsítótárazott teljes oldal a lehető legalacsonyabb TTFB-t biztosítja. Mivel a TTFB a Legnagyobb tartalmú elem betöltésének (Largest Contentful Paint) elsődleges tényezője, a gyors eredeti kiszolgáló (origin) olyan előnyt biztosít minden alatta lévő metrikának, amelyet másképp nem kaphatna meg.
De az LCP-t, a CLS-t és az INP-t leginkább a böngészőben, maga az oldal határozza meg: egy nem optimalizált fejléc kép, a renderelést blokkoló CSS és JavaScript, a betűkészletek és hirdetések betöltődése közben elmozduló elrendezés, valamint a bővítmények miatti nagy fő szálon végzett munka. Semmilyen kiszolgálói gyorsítótárazás nem hoz helyre egy 2 MB-os fejléc képet vagy egy olyan témát, amely megabájtnyi JavaScriptet küld. Az őszinte tárhelyszolgáltatás a szerver hozzájárulását gyakorlatilag ingyenessé és konzisztenssé teszi, ezután a webhely feladata, hogy a frontendet karcsúan tartsa.
A feladatmegosztás egy hasznos menti modell. Garantáljuk, hogy a kérés gyorsan eljut a böngészőbe, és az forgalom alatt is gyors marad; Ön pedig gondoskodik arról, hogy a hasznos adatcsomag kicsi és stabil maradjon. Ahol a kettő találkozik – a gyorsítótár feltöltése, az edge kézbesítés, valamint az adatbázis reakciókészségének megőrzése, hogy a dinamikus oldalak ne akadjanak el –, az pontosan az a pont, amelyre a stackünket hangoltuk, és ez az, ami miatt a felügyelt WordPress ezen a platformon gyorsabb, mint ugyanez a webhely egy általános tárhelyszolgáltatónál.
Gyakran ismételt kérdések
Szükségem van még olyan gyorsítótárazási bővítményre, mint a WP Rocket?
Nem. A teljes oldalas gyorsítótárazást a webszerveren a LiteSpeed LSCache eszköze kezeli, saját – előre telepített és automatikusan frissülő – gyorsítótár-bővítményünk pedig megfelelően összeköti ezzel a WordPress rendszert, mögötte webhelyenkénti Redis objektum-gyorsítótárral. Egy második teljes oldalas gyorsítótár-bővítmény ráépítése jellemzően a szerverszintű gyorsítótár ellen hat ahelyett, hogy segítene, így arra nincs szükség, és nem is ajánlott.
A gyorsítótárazás feltöri a WooCommerce kosaramat vagy a bejelentkezett oldalakat?
Nem. A kosár, a fizetés, a saját fiók és minden nonce vagy munkamenet oldal alapértelmezés szerint ki van zárva a gyorsítótárból, az ESI pedig élőben tartja a kosár töredékét és végösszegét a 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árat látják, miközben az áruház 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 valamit?
Az intelligens automatikus ürítés a megfelelő WordPress hookokon fut le, így a tartalom publikálása, szerkesztése, illetve egy termék, ár vagy rendelés módosítása csak az érintett oldalakat és azok archívumait törli – nem az egész gyorsítótárat –, egy keresőrobot pedig újra felmelegíti azokat. A vezérlőpultról vagy a WordPressen belülről is indíthat ürítést igény szerint.
A tárhelyszolgáltatás önmagában tökéletes Core Web Vitals eredményt tud biztosítani?
Ez biztosítja a lehető legjobb TTFB-t, ami a kiszolgáló hozzájárulása és előny az Largest Contentful Paint eléréséhez. Az LCP-t, a CLS-t és az INP-t azonban 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 mi stackünk gyorssá és egységessé teszi a kiszolgálói hozzájárulást; a front-end adatmennyiség karcsún tartása az, ami a fennmaradó rést áthidalja.
Kapcsolódó
Próbálja ki ingyen 14 napig
Indítsa el első webhelyeit ingyen 14 napig – kártya nélkül. Meglévő hálózatot költöztet? Az első migrációt mi álljuk.
Kezdje ingyen