WordPress cache na hostingu: co řeší plugin, co server a kde vznikají konflikty

Cache je nejrychlejší způsob, jak zrychlit WordPress — a zároveň nejčastější příčina toho, proč se změny na webu „neprojevují". Když víte, která vrstva co dělá, přestane být cache magií a stane se z ní nástroj, který máte pod kontrolou. Tenhle článek rozebírá, co řeší cachovací plugin, co dělá sám server a proč se obě vrstvy někdy dostanou do konfliktu.

Co je vlastně cache a proč ji WordPress potřebuje

WordPress je dynamický systém. Při každém načtení stránky by teoreticky musel spustit PHP, zeptat se databáze na obsah, poskládat šablonu a teprve pak poslat výsledek do prohlížeče. To stojí čas a výkon. Cache tenhle proces zkracuje tím, že hotový výsledek uloží a příště ho servíruje rovnou, bez opakované práce.

Háček je v tom, že „cache" není jedna věc. Ve skutečnosti jde o několik nezávislých vrstev, z nichž každá ukládá něco jiného a řídí se vlastními pravidly. Když se web chová nečekaně, skoro vždy jde o to, že si jedna vrstva pamatuje starou verzu, zatímco jiná už má novou.

Vrstvy cache, od prohlížeče k serveru

Zjednodušeně platí, že data cestují přes několik pater a na každém se můžou „zaseknout":

• Cache prohlížeče. Uložená u návštěvníka. Proto sami vidíte změnu, ale kolega ne — jeho prohlížeč drží starou verzi.
• Cache pluginu (stránková). Plugin vygeneruje statické HTML a to pak servíruje místo opakovaného spouštění PHP. Tady se řeší většina zrychlení běžného webu.
• Objektová cache. Ukládá výsledky databázových dotazů (typicky přes Redis nebo Memcached). Pomáhá u webů s hodně dynamickým obsahem, kde stránkovou cache nasadit nejde.
• Serverová cache. Webserver nebo jeho modul (například řešení typu LiteSpeed nebo reverzní proxy) drží hotové odpovědi na úrovni serveru, ještě před tím, než se vůbec spustí PHP.
• Cache CDN. Pokud používáte CDN, drží kopie souborů blíž k návštěvníkovi. Víc o tom v článku Co je CDN a kdy ji potřebuje i malý web.

Co řeší plugin a co zvládne server sám

Hranice mezi pluginem a serverem je zdroj většiny nejasností. Zjednodušené rozdělení odpovědnosti vypadá takhle:

Klíčové pravidlo zní: stránkovou cache by měla dělat jedna vrstva, ne dvě. Pokud hosting nabízí vlastní serverovou cache, cachovací plugin často nemá HTML znovu cachovat — má se soustředit na minifikaci a optimalizaci. Když obě vrstvy dělají totéž, začnou si házet klacky pod nohy.

Kde vznikají konflikty

Konflikt skoro nikdy nevypadá jako chybová hláška. Vypadá jako web, který se chová „divně". Nejčastější případy:

• Změna se neprojeví. Upravíte text nebo cenu, ale návštěvník vidí staré. Některá vrstva nedostala pokyn k pročištění.
• Rozbité rozvržení. Dvě vrstvy naráz slučují a minifikují CSS/JS, výsledek se rozjede. Typické, když plugin i server dělají optimalizaci současně.
• Přihlášený uživatel vidí cizí obsah. Cache omylem uloží stránku určenou přihlášenému a servíruje ji ostatním. Nebezpečné hlavně u košíku a účtu — proto se dynamické části nikdy nemají cachovat.
• Nekonečné přesměrování nebo chyby po migraci. Po přesunu webu drží stará cache staré adresy. Řešení popisujeme v článku Jak přemigrovat WordPress na nový hosting bez výpadku.

Jak konflikty bezpečně odladit

Postupujte od nejjednoduššího k nejsložitějšímu a měňte vždy jen jednu věc, ať víte, co pomohlo:

1. Vyčistěte všechny vrstvy naráz. Pročistěte cache pluginu, serverovou cache i CDN a otestujte v anonymním okně, aby vás nemátla cache prohlížeče.
2. Zjistěte, kdo dělá stránkovou cache. Pokud hosting cachuje na úrovni serveru, vypněte stránkovou cache v pluginu a nechte mu jen optimalizaci.
3. Vypínejte optimalizace po jedné. Slučování CSS/JS a odklad skriptů rozbíjí web nejčastěji. Zapínejte je postupně a po každém kroku web zkontrolujte.
4. Vylučte dynamické stránky. Košík, pokladna, účet a přihlášení nikdy nesmí být v cache. Většina pluginů i serverů má na to výjimky.
5. Testujte na staging webu. Změny cache patří nejdřív na kopii, ne na ostrý provoz. Proč, rozebíráme v článku Staging web: proč by ho měl mít každý WordPress.

Kdy je cache jen náplast

Cache dokáže zázraky, ale nenahradí pomalý základ. Pokud web brzdí přetížená databáze, spousta těžkých pluginů nebo poddimenzovaný tarif, cache to jen schová do chvíle, než přijde první nával nebo přihlášený uživatel, kterému se nic necachuje. Než začnete ladit cache, ověřte, jestli problém není jinde — návod najdete v článku Jak změřit rychlost hostingu a poznat, kde je problém.

Rychlý test, jestli cache vůbec funguje

Než budete cokoli ladit, ověřte, že cache reálně pracuje. Nejjednodušší test je porovnat, jak rychle se stránka načte pro nepřihlášeného návštěvníka a pro vás v administraci. Přihlášený uživatel většinou dostává necachovanou verzi, takže rozdíl v rychlosti mezi anonymním oknem a přihlášeným prohlížečem vám napoví, jestli se stránková cache vůbec uplatňuje.

Druhý signál najdete v odpovědi serveru. Cachovací pluginy i serverová cache obvykle přidávají do hlaviček odpovědi značku, jestli šlo o zásah do cache, nebo o čerstvě vygenerovanou stránku. Když načtete stejnou stránku dvakrát po sobě a druhé načtení je znatelně svižnější, cache s velkou pravděpodobností funguje. Pokud je každé načtení stejně pomalé, něco cache obchází — třeba nevyloučená dynamická podmínka nebo plugin, který si vynucuje čerstvý obsah.

Nakonec myslete na to, že cache se má po každé důležité změně obsahu sama pročistit. Když musíte pravidelně mazat cache ručně, aby se změny projevily, není to funkce, ale příznak špatného nastavení, který se vyplatí doladit.

Dobře nastavená cache je nakonec nudná: web je rychlý, změny se projevují a nikdo neřeší, proč košík ukazuje cizí zboží. Stačí vědět, že o rychlost se stará víc vrstev, každá má svou roli a stránkovou cache má dělat jen jedna z nich.