Hosting a výkon
Jak zrychlujeme WordPress: LiteSpeed Enterprise, LSCache a Redis pro každý web
Nejrychlejší požadavek na WordPress je ten, který se nikdy nespustí – zde je návod, jak naše infrastruktura odbavuje většinu návštěv z vyrovnávací paměti dříve, než se vůbec spustí PHP nebo MySQL, a co to znamená pro Core Web Vitals.
Nejrychlejší požadavek je ten, který se nikdy nespustí
Standardní požadavek na WordPress je náročný. Webový server předá požadavek PHP, PHP spustí WordPress, aktivuje pluginy, několik desítek krát odešle dotaz do MySQL, sestaví HTML a teprve poté odešle data zpět. Na vytíženém webu proběhne celá tato procedura pro každého návštěvníka a právě na ni připadá téměř celý čas do prvního bajtu.
Naším řešením je zajistit, aby u většiny návštěv k ničemu takovému vůbec nedošlo. Napříč weby, které hostujeme – více než 100 000 PBN webů a standardní spravovaný WordPress – je velká většina zobrazení stránek na front-endu doručována jako předem vykreslená celá stránka přímo z mezipaměti, aniž by se spouštěl PHP nebo přistupovalo k databázi. Zbytek tohoto příspěvku je o tom, jak vrstvy, které to umožňují, do sebe zapadají a kde každá z nich obhajuje své místo.
Důležité je si uvědomit, že nejde o konkurující si vyrovnávací paměti, mezi nimiž byste si vybírali. Mezipaměť celé stránky, objektová mezipaměť a CDN edge zachycují jinou třídu požadavků a jejich přínos spočívá v tom, jak si vzájemně předávají data.
LiteSpeed Enterprise + LSCache: vrstva celé stránky
Každý web běží na serveru LiteSpeed Enterprise s LSCache na úrovni serveru. Když je odpověď front-endu kešovatelná, webový server ji opatří hlavičkami LiteSpeed cache-control a tag, a při dalším požadavku doručí LiteSpeed celou stránku přímo – nespouští se žádný proces PHP, nevysílá se žádný dotaz MySQL. To je nejvýznamnější faktor pro TTFB systému WordPress, protože to z kritické cesty odstraňuje spouštění celé aplikace.
Protože LSCache funguje uvnitř webového serveru namísto PHP pluginu, začíná pracovat dříve v životním cyklu požadavku a uchovává stránky ve formě, kterou může server okamžitě odeslat. Crawler mezipaměti udržuje oblíbené stránky zahřáté, takže první návštěvník po vyčištění není ten, kdo platí za regeneraci stránky. Výsledkem je znatelně nižší a stabilnější TTFB než u mezipaměti založené pouze na pluginu přidané ke generickému zásobníku, kde mezipaměť stále stojí za PHP.
Náš vlastní cache plugin na úrovni repozitáře je předinstalovaný a automaticky se aktualizuje na každém webu, takže propojuje WordPress s LSCache správně hned po vybalení. Na originálním serveru, který nepoužívá LiteSpeed, jednoduše nevysílá hlavičky pro celou stránku a jde stranou, zatímco objektová cache a pravidla výjimek dál plní svou roli – takže migrovaný web nikdy nezůstane v rozbitém napůl nakonfigurovaném stavu.
Zachování rychlosti bez poskytování zastaralých dat: ESI a chytré automatické čištění mezipaměti
Agresivní celostránkové ukládání do mezipaměti má dva klasické typy selhání: zobrazení stránky někoho jiného přihlášenému uživateli a zobrazení stránky, která se měla změnit, komukoliv. Oba se řeší na vrstvě mezipaměti namísto menšího ukládání do mezipaměti.
ESI (Edge Side Includes) nám umožňuje ukládat stránku do mezipaměti a zároveň vytvořit výjimky pro části, které musí zůstat aktuální. V obchodě WooCommerce jsou stránky katalogu, produktů a kategorií poskytovány z mezipaměti celé stránky pro co nejrychlejší TTFB, zatímco ESI vykresluje fragment košíku, součty v mini košíku a stav účtu pro každý požadavek. Košík, pokladna, můj účet a všechny stránky s nonce nebo relací jsou ve výchozím nastavení vyloučeny. Zákazníci tak vždy vidí svůj vlastní košík a funkční pokladnu, přičemž všichni ostatní získávají vzhled obchodu z mezipaměti.
Aktuálnost je zajištěna chytrým automatickým promazáváním. Háčky pro promazávání se spouštějí automaticky při změně obsahu, produktů, cen nebo objednávek, takže se příslušné uložené stránky obnoví okamžitě namísto čekání na časovač a paměť můžete promazávat také na vyžádání z ovládacího panelu nebo přímo z prostředí WordPress. Promazávání na základě štítků znamená, že úprava jednoho příspěvku vymaže daný příspěvek a jeho archivy – nikoli celou mezipaměť –, takže jedna úprava nezpůsobí studený start celého webu.
Objektová vyrovnávací paměť Redis pro jednotlivé weby: pro to, co nemůže být celou stránkou
Ne každý požadavek může být statickou celou stránkou. Přihlášené relace, administrace WordPress, košíky WooCommerce, vyhledávání a dynamické fragmenty, které po sobě ESI zanechává, musí všechny spouštět PHP. U nich se cíl mění z „přeskočit aplikaci“ na „přeskočit databázi“.
Každý web má svou vlastní dedikovanou Redis objektovou cache. WordPress ukládá výsledky opakovaných čtení z databáze – možnosti, přechodná data, vyhledávání příspěvků a termínů, data produktů a relací WooCommerce – do paměti, takže se stejný dotaz nespouští nad MySQL při každém požadavku. Účinek je nejviditelnější právě tam, kde mezipaměť celé stránky pomoci nemůže: rychlejší administrace, rychlejší nákupní košíky a mnohem nižší zátěž databáze při vysoké návštěvnosti.
Objektová vyrovnávací paměť je pro každý web zvlášť, není sdílená, což má význam jak pro výkon, tak pro izolaci. V kombinaci s omezováním výkonu databáze pro jednotlivé weby nemohou náročné nebo špatně napsané dotazy jednoho webu vyčerpat databázi pro sousední weby. Více o tom, jak celé vícefázové nastavení dohromady funguje, si můžete přečíst na naší stránce o funkcích mezipaměti a o hranicích mezi nájemníky v rámci izolace.
Okraj a přenos pod ním
Mezipaměť, která žije na originálu, musí stále přejít přes síť. Před serverem se nachází edge CDN, takže statické assety a stránky, které lze ukládat do mezipaměti, jsou obsluhovány z bodu přítomnosti poblíž návštěvníka a originál zůstává klidný i při zátěži. U naší řady hostingu Footprint-Free je stejný edge tvořen multi-CDN poolem rozloženým mezi několik poskytovatelů, což slouží jak cílům v oblasti footprintu, tak i výkonu; u běžného WordPress je to jednoduše rychlá, dobře fungující vrstva, která udržuje originály v nečinnosti.
Pod kapotou se na ničem nešetří. Weby běží na úložišti NVMe s podporou HTTP/3, takže data, která cache odesílá, dorazí přes moderní multiplexovaný přenos, přičemž v případě neúspěchu v cache je k dispozici rychlé úložiště. Žádná z těchto vrstev není příplatkovým doplňkem: LiteSpeed, LSCache, Redis pro jednotlivé weby, NVMe a HTTP/3 jsou základem u každého tarifu, nikoliv placeným navýšením.
Co ve skutečnosti hýbe Core Web Vitals
Vyplatí se být přesný, protože hosting bývá na Core Web Vitals často nadhodnocovaný. TTFB je tou částí rovnice, kterou má ve vlastnictví server, a nadřazená vrstva mezipaměti je to, co jej stlačuje dolů – ucelená stránka v mezipaměti doručená přes protokol HTTP/3 z edge serveru dosahuje zhruba tak nízkých hodnot TTFB, jak je to jen možné. Jelikož TTFB tvoří počáteční fázi metriky Largest Contentful Paint, rychlý origin poskytuje všem navazujícím metrikám náskok, který by jinak nemohly získat.
Ale metriky LCP, CLS a INP se rozhodují většinou v prohlížeči, přímo na stránce: neoptimalizovaný hlavní obrázek (hero image), CSS a JavaScript blokující vykreslování, rozvržení, které se posouvá při načítání písem a reklam, a náročná práce hlavního vlákna ze strany pluginů. Žádné množství serverové mezipaměti nevyřeší 2MB hlavní obrázek ani šablonu, která načítá megabyty JavaScriptu. Poctivý hosting zajistí, že podíl serveru je prakticky zanedbatelný a stabilní, a pak už je na samotném webu, aby udržel front-end v úsporném stavu.
Tato dělba práce je užitečným mentálním modelem. Garantujeme, že požadavek dorazí do prohlížeče rychle a zůstane rychlý i při vysoké návštěvnosti; vy se staráte o to, aby byl obsah malý a stabilní. Místo, kde se tyto dvě věci setkávají – zahřívání mezipaměti, doručování na okraji sítě (edge delivery) a udržování rychlé odezvy databáze, aby se dynamické stránky nezastavovaly – je přesně to, na co je náš stack vyladěný, a právě to činí spravovaný WordPress na této platformě rychlejším než tentýž web na běžném hostingu.
Často kladené otázky
Potřebuji stále ještě vyrovnávací paměť (caching plugin) jako je WP Rocket?
Ne. Úplné ukládání do mezipaměti na úrovni webového serveru zajišťuje LSCache od LiteSpeed a náš vlastní plugin mezipaměti – předinstalovaný a s automatickými aktualizacemi – k němu správně připojuje WordPress, přičemž v pozadí funguje objektová mezipaměť Redis pro každý web. Přidání druhého pluginu pro úplné ukládání do mezipaměti obvykle bojuje proti mezipaměti na úrovni serveru, místo aby pomáhalo, takže to není potřeba a nedoporučuje se to.
Způsobí mezipaměť (caching) problémy s mým košíkem v WooCommerce nebo s přihlášenými stránkami?
Ne. Stránky košíku, pokladny, mého účtu a veškeré stránky s nonce nebo relací jsou ve výchozím nastavení z mezipaměti vyloučeny a prvek ESI udržuje fragment košíku a součty aktuální na stránkách, které jsou jinak v mezipaměti uloženy. Zákazníci tak vždy vidí svůj vlastní košík a fungující pokladnu, zatímco výloha obchodu se stále načítá z mezipaměti.
Jak zůstává mezipaměť aktuální, když publikuji nebo upravuji?
Inteligentní automatické mazání funguje na příslušných háčkech WordPress, takže publikování, úprava obsahu nebo změna produktu, ceny či objednávky vymaže pouze dotčené stránky a jejich archivy – nikoli celou vyrovnávací paměť – a crawler je opět zahřeje. Vymazat můžete také na vyžádání z dashboardu nebo přímo z prostředí WordPress.
Může mi samotný hosting zajistit dokonalé Core Web Vitals?
Poskytuje vám nejlepší možný TTFB, což je podíl serveru a náskok pro metriku Largest Contentful Paint. O LCP, CLS a INP však do velké míry rozhoduje samotná stránka – velikosti obrázků, prostředky blokující vykreslování, stabilita rozvržení a JavaScript na hlavním vlákně. Náš stack zajišťuje, že přínos serveru je rychlý a stabilní; udržování štíhlého front-endového payloadu je to, co zacelí zbytek mezery.
Související
Vyzkoušejte zdarma na 14 dní
Spusťte své první weby na 14 dní zdarma – bez platební karty. Přesouváte existující síť? První migrace je na nás.
Začít zdarma