Cache v PrestaShopu není jeden přepínač

Když řeším rychlost PrestaShopu, nejprve rozlišuji, na co zákazník vlastně čeká. Dlouhá odezva serveru při otevření kategorie má jinou příčinu než pomalé stažení velkých fotografií. A rychlá úvodní stránka ještě neznamená rychlý košík. Cache neboli mezipaměť pomáhá tím, že jednou vytvořený výsledek použije znovu. Podstatné ale je, jaký výsledek ukládá, komu jej může zobrazit a kdy pozná, že už neplatí.

V PrestaShopu se potkává cache šablon, datová cache, mezipaměť samotného PHP, cache prohlížeče i případná cache celých stránek. Každá řeší jinou část požadavku. Označení voleb se navíc liší mezi verzemi a překlady administrace. Následující přehled proto zahrnuje současné možnosti i technologie, se kterými se setkáte při správě starších obchodů. Přítomnost položky v administraci sama o sobě nepotvrzuje, že ji daný hosting dokáže používat.

Smarty: kompilace šablon a ukládání jejich výstupu

V administraci obvykle začínám v části Pokročilé parametry → Výkon. Smarty převádí šablony motivu do podoby, kterou může PHP vykonat. Vynucená kompilace při každém načtení patří k vývoji a hledání chyb; v běžném provozu zbytečně přidává práci. Praktickou volbou bývá překompilování při změně souboru. Režim bez kontroly změn dává smysl tam, kde je spolehlivě vyřešené vyčištění cache při nasazování úprav. Vedle kompilace existuje také ukládání výstupu šablon, které využívají jednotlivé části obchodu a správně napsané moduly. Zapnutí Smarty cache ovšem automaticky nevytvoří bezpečnou statickou kopii každé kompletní stránky pro všechny zákazníky. U modulů záleží na jejich implementaci a rozlišení kontextu. Po úpravách kontroluji zejména ceny, dostupnost, jazyk a přihlášeného zákazníka. Základní volby popisuje dokumentace nastavení výkonu PrestaShopu.

Souborové úložiště, databáze a automatické čištění

U verzí, které dovolují vybrat úložiště Smarty cache, je potřeba oddělit souborový systém od ukládání do MySQL. Pro běžný obchod na jednom serveru zpravidla začínám souborovou cache na rychlém místním disku. Přesun do databáze nemusí nic urychlit: můžete jen přidat práci databázi, která už obsluhuje katalog a objednávky. Naopak pomalé síťové úložiště nebo velké množství drobných souborů si zaslouží samostatné měření. Důležité je také nastavení čištění po změnách produktů a motivu. Příliš časté mazání snižuje přínos mezipaměti; nedostatečné zneplatňování ponechá starý obsah. U více aplikačních serverů je nutné řešit synchronizaci a dostupné optimalizace pro více frontendů. Nelze předpokládat, že lokální soubory jednoho serveru automaticky uvidí ostatní. Doporučení k souborové cache a diagnostice modulů uvádí vývojářský průvodce optimalizací.

CCC: chytrá cache pro CSS

CCC znamená Combine, Compress and Cache. U stylů jde především o zpracování a ukládání připravených CSS souborů, takže se stejná práce nemusí opakovat při každém požadavku. Zapnutí může omezit přenášený objem a podle konkrétní verze a motivu i počet souborů. Výsledek však vždy ověřuji na skutečné stránce: zejména mobilní nabídku, produktovou galerii, filtry a pokladnu. Nekvalitně zapsané styly nebo nesprávné cesty k obrázkům mohou po zpracování odhalit chyby, které předtím nebyly vidět. Současně nedává smysl posílat zákazníkovi obrovský společný soubor obsahující styly desítek nepoužitých funkcí. U HTTP/2 a HTTP/3 už samotné snížení počtu požadavků není dostatečný důvod pro slučování všeho. Sleduji velikost, využití a dopad na první vykreslení, nikoli jen zapnutý přepínač.

CCC: chytrá cache pro JavaScript a nastavení serveru

JavaScript vyžaduje opatrnější postup než CSS. Skripty modulů mohou záviset na přesném pořadí načítání nebo na knihovně, kterou dodává motiv. Po zapnutí chytré cache proto zkouším změnu kombinace produktu, vložení do košíku, přihlášení, dopravce i platební metody. Chyba se někdy projeví až na určitém telefonu nebo po přihlášení. Pokud verze administrace nabízí další optimalizace HTML či načítání skriptů, posuzuji je stejným způsobem a zapínám postupně. Zpracování souborů v CCC navíc není totéž jako přenosová komprese gzip nebo Brotli: tu řeší webový server či CDN. Volba optimalizace Apache se vztahuje k odpovídajícímu prostředí; konfiguraci Nginxu nenahradí. Konkrétní implementaci zpracování souborů lze ověřit i ve zdrojovém kódu třídy Media.

Nativní datová cache: co znamenají Memcache, Memcached, APC a Xcache

Samostatná sekce pro systém ukládání do mezipaměti vybírá backend datové cache. Nejde o stejné nastavení jako cache Smarty a neznamená to, že se veškerá databázová práce obchodu automaticky přesune do RAM. Přínos závisí na tom, které části jádra a modulů tuto vrstvu skutečně používají, jak často data opakují a kolik stojí komunikace s úložištěm. Z nabízených backendů se pro tuto vrstvu vybírá jeden; všechny čtyři se nezapínají současně. Před změnou porovnávám odezvu s cache i bez ní, při prázdné i zahřáté mezipaměti. Architektura cache PrestaShopu zároveň ukazuje, proč je potřeba rozlišovat jednotlivé mechanismy uvnitř aplikace.

Memcached přes PHP::Memcache

První možnost používá serverovou službu Memcached, se kterou PHP komunikuje prostřednictvím rozšíření Memcache, tedy bez koncového „d“. Samotná instalace služby nestačí; příslušné rozšíření musí být načtené také v PHP, které obsluhuje web. Kontrola příkazového PHP nemusí potvrzovat stav PHP-FPM použitého obchodem. V PrestaShopu se podle dostupného rozhraní zadává adresa serveru, port a případně váha. Na jednom stroji může jít o místní službu, u více aplikačních serverů o společné úložiště. To ovšem přidává síťovou komunikaci, a proto nemá smysl slibovat zrychlení bez měření. Správce musí zajistit také dostatek paměti a neveřejnou dostupnost služby. Data v Memcached mohou být vytlačena při zaplnění paměti a nejsou trvalým úložištěm objednávek. Instalační požadavky uvádí manuál rozšíření Memcache; způsob připojení dokládá nativní adaptér PrestaShopu.

Memcached přes PHP::Memcached

Druhá možnost používá stejný typ serverové služby, ale jiné PHP rozšíření: Memcached, tentokrát s koncovým „d“. Je postavené na knihovně libmemcached a má vlastní rozhraní i instalační závislosti. Rozšíření Memcache a Memcached nejsou zaměnitelná; volba v administraci musí odpovídat skutečné instalaci na serveru. U nově připravovaného prostředí bych tuto variantu zařadil mezi kandidáty podle podpory hostingu, verze PHP a výsledků testu. Automaticky rychlejší však být nemusí. Sleduji úspěšnost zásahů do cache, využití paměti, vytlačování položek i prodlevy spojení. Ověřuji také, že jednotlivé instalace mají vhodně oddělené klíče a že vymazání cache neovlivní jiný obchod. Pro více frontendů může společná služba usnadnit sdílení dat, sama ale nesynchronizuje všechny ostatní cache v aplikaci. Podmínky instalace najdete v manuálu Memcached a konkrétní chování v adaptéru CacheMemcached.

APC a APCu: místní datová cache

U označení APC je potřeba dát pozor na historický název. Původní APC spojovalo ukládání uživatelských dat a zkompilovaného PHP kódu. V současném prostředí je pro uživatelská data relevantní APCu, zatímco PHP kód obvykle řeší OPcache. Odkaz často uváděný u volby APC proto vede právě na instalaci APCu. Nejde jen o přejmenování: musí se ověřit podpora v konkrétní verzi PrestaShopu. Například adaptér CacheApc v řadě 8.2 výslovně pracuje s APC i APCu. Výhodou místní sdílené paměti je absence spojení na vzdálený cache server. Rozsah sdílení však závisí na způsobu provozu PHP; nejde o společnou síťovou cache více strojů. Při nasazení sleduji vyhrazenou paměť a chování po restartu PHP. Důležitá praktická drobnost: vyčištění APCu z příkazové řádky nemusí vyčistit stejnou paměť, kterou používají webové procesy.

Xcache: možnost, kterou je třeba zasadit do historie

Xcache se ve starších instalacích a seznamech PrestaShopu objevuje oprávněně. Rozšíření poskytovalo cache PHP kódu i uživatelských proměnných a příslušný adaptér umožňoval využít datovou část. Pro nový obchod na současném PHP jej ale nedoporučuji volit jen proto, že zůstalo uvedené v nabídce. Historie projektu popisuje zejména generaci PHP 5, což je zásadní rozdíl proti dnešním serverům. Nejprve je nutné doložit kompatibilitu konkrétního rozšíření s používaným PHP a jeho údržbu. U převzatého starého obchodu má smysl zjistit, zda Xcache opravdu běží a co na něm závisí; následně naplánovat modernizaci celého prostředí. Návrat na zastaralé PHP kvůli jedné cache by byl špatný obchod. Původní projekt je dostupný v repozitáři Xcache, nelze jej však považovat za obecný instalační návod pro současný PrestaShop.

OPcache a aplikační cache: další důležité vrstvy

PHP OPcache ukládá předkompilovaný PHP kód, takže jej server nemusí při každém požadavku znovu zpracovávat od začátku. Pro provoz PrestaShopu je to důležitá součást serverového prostředí, není to ale další datový backend v uvedeném seznamu. Kontroluji aktivaci pro webové PHP, přidělenou paměť a rezervu pro počet souborů. U agresivního nastavení bez kontroly změn je nutné při aktualizacích zajistit obnovení kódu v cache. Vedle toho PrestaShop používá interní aplikační cache, v moderních částech také mechanismy Symfony. Vyčištění této vrstvy může být potřeba po změně služeb nebo nasazení modulu. Tlačítko „Vymazat cache“ přitom neznamená, že současně zmizí kopie v prohlížeči, ve všech modulech a na Cloudflare. Při hledání starého obsahu vždy určuji, ve které vrstvě zůstává.

Cache prohlížeče a HTTP hlavičky

Dobře nastavený server dovolí prohlížeči znovu použít obrázky, styly, skripty a písma. Zákazník je pak při další návštěvě nemusí celé stahovat. O tom rozhodují zejména hlavičky Cache-Control a případně Expires; ETag či Last-Modified pomáhají ověřit, zda se soubor změnil. Dlouhá platnost je vhodná pro statické soubory, jejichž URL se při aktualizaci mění. Jinak si zákazník může ponechat staré CSS i po vymazání cache obchodu. Personalizované HTML potřebuje odlišná pravidla než produktová fotografie. Konkrétní příklady pro statické soubory uvádí dokumentace konfigurace Apache. U Nginxu se nastavuje odpovídající konfigurace serveru. V praxi kontroluji skutečné hlavičky odpovědi, protože zamýšlená konfigurace a to, co zákazník dostává přes proxy, se mohou lišit.

Cache moduly z addons.prestashop.com

Na oficiálním tržišti najdete například Page Cache Pro nebo Page Cache Ultimate. Jde o příklady produktů k porovnání, nikoli o univerzální doporučení pro každý obchod. Moduly této kategorie mohou ukládat celé stránky nebo rozsáhlejší části výstupu. Při zásahu do cache tak nemusí PHP znovu sestavovat všechen obsah. Přínos bývá nejzajímavější u veřejných katalogových stránek, ale před nákupem ověřuji podporovanou verzi PrestaShopu, PHP, motivu a důležitých modulů. Dále mě zajímá způsob aktualizace dynamických bloků, automatické zneplatnění po změně produktu a předehřívání cache. Marketingové skóre samo neřekne, jak se modul zachová u vašich cenových pravidel a pokladny.

Rozhodující je správný klíč cache: stejná URL může podle situace zobrazovat jiný jazyk, měnu, daň, cenu pro zákaznickou skupinu nebo nabídku konkrétního obchodu. Košík, účet, objednávka, personalizované odpovědi a platební návraty musí mít odpovídající vyloučení či bezpečné dynamické řešení. U anonymního návštěvníka zase potřebuji ověřit okamžik, kdy začne nakupovat. Kvalitní modul musí umožnit kontrolu těchto scénářů a rozumné mazání dotčených stránek. Zkoušku provádím na kopii obchodu a porovnávám rychlost i správnost. Dva moduly, které oba cachují celou stránku, obvykle přidají hlavně komplikace při určování, odkud pochází zastaralý obsah.

Media servery: propojení PrestaShopu se statickým obsahem

Nativní položka Media servery umožňuje směrovat podporované statické soubory na jinou doménu či subdoménu, například na CDN, tedy distribuovanou síť pro doručování obsahu. Samotné vyplnění adresy ale soubory nepřekopíruje a nevytvoří distribuci obsahu. Nejdřív musí cílová adresa skutečně poskytovat požadované obrázky, CSS a JavaScript. Poté se ověří HTTPS certifikát, správné cesty, dostupnost a u písem také případná pravidla CORS. Subdoména namířená na stejný server může organizačně posloužit, sama však nepřidá výpočetní výkon ani geograficky bližší kopii souborů. Historické doporučení rozdělovat soubory mezi několik domén kvůli paralelnímu stahování je navíc potřeba posuzovat v kontextu HTTP/2 a HTTP/3. Další domény mohou přidat navazování spojení. Media server proto zapojuji s konkrétním cílem a měřením, nejčastěji jako součást skutečné CDN.

Cloudflare: nejprve statické soubory, potom případně HTML

Cloudflare může před obchodem fungovat jako reverzní proxy a CDN. Při správném nastavení obsluhuje část statického obsahu ze své distribuované sítě a omezuje opakované přenosy z původního serveru. Ve výchozím nastavení ovšem necachuje běžné HTML ani JSON. Pouhé přepnutí DNS tedy neznamená, že se přestanou vytvářet produktové stránky v PHP. Pro základní nasazení zpravidla není nutné současně měnit položku Media servery: Cloudflare může pracovat přímo před hlavní doménou. Kontroluji skutečné zásahy do cache pomocí hlaviček a přehledů služby, ne jen její zapnutí. Výchozí pravidla a respektování hlaviček původního serveru popisuje dokumentace chování Cloudflare Cache.

Cachování HTML na okraji sítě už vyžaduje návrh pravidel pro konkrétní obchod. Plošné „Cache Everything“ může bez správných výjimek uložit obsah závislý na zákazníkovi. Nestačí vyloučit jednu adresu košíku: je nutné zohlednit routy, parametry, cookies, přihlášení a různé cenové kontexty. Dostupnost podmínek a možností klíče cache navíc závisí na službě a tarifu. Pravidla pro vynechání cache podle cookie jsou jedním z nástrojů, nikoli hotovou univerzální konfigurací PrestaShopu. Po změně produktu musí být vyřešeno i zneplatnění příslušných kopií. U propojení s cache modulem předem určuji, kdo a kdy vyčistí každou vrstvu.

Pokročilejší provoz: reverzní proxy, Varnish a Redis

Na vlastním serveru lze navrhnout také FastCGI cache v Nginxu nebo reverzní proxy, například Varnish. Je to další způsob ukládání HTTP odpovědí, který opět potřebuje výjimky, správné rozlišení zákazníků a navázané čištění. Redis bývá využitelný přes vhodný modul či vlastní integraci pro konkrétní cache nebo session; nelze jej automaticky zaměnit za jednu ze čtyř zde uvedených nativních voleb. U takového řešení chci znát přesnou odpovědnost každé komponenty a mít zajištěnou správu serveru. Nasazovat více technologií jen proto, že se uvádějí v seznamech optimalizací, nepovažuji za dobrý důvod. Obchod musí zůstat předvídatelný i při restartu služby, importu katalogu a vyprázdnění mezipaměti.

Jak bych cache nastavoval u konkrétního obchodu

Začal bych měřením bez změn: odezvou serveru, databázovými dotazy, náročností modulů a velikostí přenášených souborů. Opravil bych zjevně pomalé části, ověřil produkční režim, OPcache a Smarty. Následovaly by CSS, JavaScript, obrázky a hlavičky statických souborů. Teprve podle výsledků bych přidal datový backend, cache modul nebo CDN. Pomalou databázovou operaci při dokončení objednávky totiž nezachrání statická kopie úvodní stránky.

Každou změnu porovnávám při prvním i opakovaném načtení, na mobilu a pro různé zákaznické scénáře. Vedle TTFB, tedy doby do prvního bajtu odpovědi, a vykreslení hlavního obsahu kontroluji aktuálnost ceny, změnu skladu, slevový kód, dopravu a celý průchod pokladnou. Důležitá je i rychlost po vymazání cache, protože právě tehdy se ukáže skutečná náročnost obchodu. Dobře navržená cache zrychluje prodej a přitom zachovává správná data. Potřebujete-li vybrat vhodnou kombinaci pro svůj obchod, v rámci optimalizace rychlosti PrestaShopu nejprve prověřím jeho konkrétní omezení a podle nich navrhnu postup.