Proč je váš obchod na PrestaShopu tak pomalý? Pravda o modulech, hostingu a pasti „headless“

Tento scénář se opakuje téměř každý týden. Obrací se na nás zoufalý majitel e-shopu: obchod na platformě PrestaShop se v době špičky načítá 4–6 sekund, zákazníci opouštějí nákupní košíky a kampaně Google Ads či Meta Ads vyčerpávají rozpočet kvůli vysoké míře odchodů.

První reakce podnikatele? „Asi máme příliš slabý server.” Následuje tedy upgrade balíčku u poskytovatele hostingu, migrace na výkonný VPS a často i nákup dedikovaného serveru za 1 000 či 1 500 zlotých měsíčně. Výsledek? Web získal zlomek sekundy, faktura za infrastrukturu se několikrát zvýšila, databáze se při sebemenší akci stále zhroutí a internetový obchod se zasekává přesně stejně jako dřív.

Pravda bývá nepříjemná: Můžeš si koupit server velikosti malé jaderné elektrárny, ale pokud je kód obchodu špatně optimalizovaný, databáze se stejně zhroutí.

Kde leží skutečný zdroj problému? V praxi se to dá shrnout do dvou hlavních příčin.

1. Smetiště modulů a SQL dotazů, které ničí databázi

PrestaShop je výkonný a flexibilní systém s rozsáhlým ekosystémem hotových řešení. To je jeho největší výhoda, ale zároveň i zdroj největších problémů s výkonem. Mnozí majitelé e-shopů a nezkušení vývojáři zacházejí s moduly jako s kostkami Lego: „potřebuji vyskakovací okno – stáhnu si modul”, „chci lištu s bezplatnou dopravou – další modul”, „karusel s recenzemi – třetí modul”.

Tímto způsobem v obchodě začne fungovat 60, 80 a někdy i více než 100 modulů třetích stran. Problém spočívá v tom, že velká část z nich pochází od náhodných vývojářů z tržišť a byla napsána bez dodržení základních standardů softwarového inženýrství.

Tyto moduly jsou z hlediska práce s databází velmi špatně optimalizovány:

• Chybějící indexy v tabulkách: Modul vytváří vlastní tabulky v MySQL, ale autor opomíjí indexovat sloupce, podle nichž později filtruje data. Výsledek? Při každém dotazu databáze provádí tzv. úplné prohledání tabulky – prohledává stovky tisíc řádků od začátku do konce, místo aby okamžitě vyhledal konkrétní záznam.
• Závažný problém dotazů typu N+1: Špatně napsaný modul – místo toho, aby načítal data pro 20 produktů v seznamu kategorií jedním optimalizovaným dotazem z PŘIPOJTE SE, provádí samostatný dotaz do databáze pro každý jednotlivý produkt v seznamu. Vynásobte to deseti nekvalitními moduly a 50 uživateli, kteří současně procházejí katalog – databáze tak za zlomek sekundy provede tisíce zbytečných a náročných operací.
• Žádné ukládání do mezipaměti: Náročné výpočty a dotazy se provádějí znovu při každém načtení stránky, místo aby se zpracovaný výsledek uložil do mezipaměti.

Ve výsledku tedy úzkým hrdlem není ani výpočetní výkon procesoru, ani množství paměti RAM na serveru. Úzkým hrdlem se stává zablokovaná fronta dotazů do MySQL, která prodlužuje dobu odezvy serveru (TTFB) na několik sekund.

2. Špatný hosting a nevhodná architektura prostředí

Druhým důvodem je infrastruktura, která v reklamních prospektech slibuje „neomezený přenos dat a spoustu gigabajtů”, ale ve skutečnosti nemá nic společného s prostředím optimalizovaným pro e-commerce aplikace.

PrestaShop je rozsáhlý systém založený na jazyce PHP a relační databázi. Vyžaduje především velmi rychlý jednojádrový procesor (vysoký takt Single Core Performance), nikoli desítky pomalých jader. Kromě toho vyžaduje specifickou konfiguraci prostředí:

• Chybí agresivní ukládání kódu do mezipaměti pomocí OPcache s dostatečně velkým limitem mezipaměti,
• Obchod běží na zastaralé verzi PHP (např. 7.4 místo 8.1 nebo 8.2), což automaticky snižuje výkon při čistém spouštění skriptů o 20-30%,
• Databázový engine pracuje s výchozími bezpečnostními nastaveními poskytovatele (příliš malý fond innodb_buffer_pool_size), což má za následek, že MySQL místo toho, aby pracoval s rychlou pamětí RAM, neustále načítá data z disku,
• Chybí integrovaná mezipaměť v paměti RAM (např. Redis nebo Memcached), který by převzal správu relací uživatelů a systémových objektů a tím odlehčil hlavní databázi.

Je to všechno? Rozhodně ne – potřebujete synergii (1 + 2)

Můžete mít dokonale nakonfigurovaný dedikovaný server, který vyladil nejlepší správce systémů na trhu. Pokud je však váš obchod na PrestaShopu přetížen neoptimálními moduly, které generují stovky chaotických dotazů do databáze – Ten rychlý hosting nic nezachrání. Databáze se stejně ucpe a zdroje serveru se zbytečně vyčerpají.

Funguje to i opačně: můžete mít dokonale optimalizovanou, odlehčenou šablonu a vyčištěnou databázi bez zbytečné zátěže. Pokud však tento obchod umístíte na levný, přetížený sdílený hosting za 100 zł ročně, kde stovky dalších stránek soupeří o stejný procesorový vlákno – obchod bude i tak fungovat pomalu.

Maximální výkonnost v e-commerce je vždy rovnice: Lehký, optimalizovaný e-shop + serverová architektura přizpůsobená pro PrestaShop. Jedno bez druhého prostě neexistuje.

Headless PrestaShop – vyplatí se do toho jít?

V souvislosti s problémy s výkonností v odvětví e-commerce se objevil určitý trend. Mnoho agentur nabízí „moderní” řešení: „Pojďme vytvořit headless řešení! Odpojme standardní frontend, nasadíme aplikaci v Next.js nebo Nuxt a PrestaShop necháme pouze jako engine běžící na pozadí a propojený přes API.”.

Teoreticky to zní moderně a prestižně. A v praxi? Přestavba PrestaShopu na headless je v drtivé většině případů katastrofální nápad.

Víme to z první ruky. Už se k nám dostaly 2–3 projekty, které předchozí dodavatelé rozběhli a nedokončili právě kvůli tomu, že narazili na omezení architektury typu „headless“. Zákazníci utratili obrovské rozpočty, zůstali s nefunkčními e-shopy a ocitli se zpět na začátku. Jak to dopadlo? Místo toho, abychom se pouštěli do této slepé uličky, jsme tyto e-shopy postavili od nuly na klasické, propracované architektuře v PHP. Výsledek? Z hlediska rychlosti a výkonu jsme dosáhli výsledků v podstatě identických s těmi, které slibovala architektura „headless“, a zákazníci se vyhnuli celé řadě závažných technologických problémů:

• Tím architekturu výrazně komplikuješ: Místo jednoho uceleného systému musíte spravovat, monitorovat a platit za dvě zcela oddělená prostředí – aplikaci Node.js obsluhující frontend a engine PrestaShop na backendu. To zdvojnásobuje počet potenciálních míst selhání.
• Ztrácíte kompatibilitu s 90% hotových modulů dostupných na trhu: Zapomeňte na instalaci modulu platební brány, balíkových automatů, systému splátek nebo marketingových nástrojů jedním kliknutím. Každý modul, který zasahuje do vzhledu obchodu, musí být ručně integrován od nuly a naprogramován na úrovni frontendu v JavaScriptu.
• Obrovské náklady na údržbu: Každá, i ta nejmenší úprava šablony, změna v nákupním košíku nebo přidání nového banneru vyžaduje zapojení full-stack vývojářů, což zvyšuje náklady na běžnou údržbu e-shopu o stovky procent.

A co samotný výkon?

Pravda je taková, že Dobře optimalizovaný, lehký a specializovaný šablona postavená na klasickém jádru PrestaShop dosahuje v testech Google PageSpeed výsledků v rozmezí 90–98 bodů na mobilních zařízeních.

Rozdíl v rychlosti fungování pro koncového uživatele mezi propracovanou klasickou šablonou a headless architekturou je zanedbatelný a často nepostřehnutelný. Naopak rozdíl v složitosti procesu, rozpočtu na implementaci a následných nákladech na údržbu je prostě obrovský.

Jak začít s opravou pomalého obchodu?

Než utratíte další tisíce za výkonnější server nebo se pustíte do riskantního rozhodnutí o přepracování e-shopu na moderní technologie, začněte s konkrétními údaji a základními zásadami technické hygieny:

1. Zapněte Profiler PrestaShop v testovacím prostředí: Podívejte se podrobně, které dotazy do databáze trvají nejdéle, které tabulky jsou přetížené a které moduly způsobují největší zpoždění při generování stránky.
2. Proveďte důkladný audit modulů: Vypněte a odinstalujte vše, co nepřináší přímou prodejní hodnotu. Nahraďte 5 nekvalitních modulů s jednoduchými animacemi čistým kódem v šabloně.
3. Optimalizujte tabulky MySQL: Projděte strukturu databáze, odstraňte fiktivní košíky, vymažte systémové protokoly a doplňte chybějící indexy v tabulkách externích modulů.
4. Zajistěte vhodné prostředí: Ujistěte se, že váš server běží na nové verzi PHP, má nakonfigurovaný OPcache a podporuje Redis jako objektovou mezipaměť.
5. Sázejte na speciální, lehký motiv: Místo přetížených hotových šablon se stovkami zbytečných funkcí si vyberte šablonu přizpůsobenou vašim skutečným potřebám – bez zbytečného kódu CSS a JavaScriptu, který brzdí načítání stránky.

Rychlý PrestaShop není otázkou „magie” ani utrácení rozpočtu za předimenzované servery. Je to otázka poctivé programátorské práce, přehlednosti v databázi a správně zvolených základů infrastruktury.