Přeskočit na obsah

Pomalý e-shop ztrácí zákazníky. Najdeme proč a zrychlíme ho.

Diagnostikujeme skutečnou příčinu pomalého e-shopu — přetíženou databázi, špatně nastavený PHP-FPM, chybějící cache nebo N+1 dotazy. Optimalizaci výkonu vždy podkládáme měřením, ne odhadem.

PHP-FPM Redis · OPcache MySQL · slow query log měřitelný výsledek

Rychlost e-shopu je přímý obchodní faktor. Každá vteřina navíc v načítání stránky snižuje konverzní poměr, zhoršuje pozice ve vyhledávání a zvyšuje míru opuštění košíku. Přesto pomalý e-shop málokdy způsobuje slabý hardware — mnohem častěji jde o databázové bottlenecky, neefektivní kód a chybějící cache, které se naplno projeví až ve špičkách.

Optimalizace výkonu u nás nezačíná nákupem většího serveru. Začíná měřením. Teprve když víme, kde se čas reálně ztrácí — v databázi, v aplikaci, v síti nebo v konfiguraci PHP-FPM — má smysl zasahovat. Cílem je měřitelné a trvalé zrychlení, ne dočasná úleva, která se vrátí při prvním výprodeji.

Jaké problémy řešíme

  • Pomalé SQL dotazy — chybějící indexy, N+1, full table scany
  • Databázové bottlenecky při paralelních požadavcích
  • Špatně nastavený PHP-FPM — pool size, timeouty, memory limit
  • Chybějící nebo neúčinná cache — Redis, OPcache, page cache
  • Výpadky výkonu ve špičkách, při slevách a výprodejích
  • Pomalá administrace e-shopu, importy a exporty
  • Rostoucí TTFB a zhoršující se Core Web Vitals

Typické symptomy

perf.log · co slýcháme
symptomWARN„e-shop zpomaluje při větším provozu"
symptomWARN„ve špičkách padá nebo hází 502"
symptomWARN„administrace je pomalá, import trvá hodiny"
symptomWARN„jeden dotaz blokuje celou databázi"
symptomWARN„hosting říká, že je problém v kódu"
symptomWARN„zvětšili jsme server, ale nepomohlo to"

Od diagnostiky k měřitelnému zrychlení

Postupujeme systematicky. Nejprve změříme výchozí stav — p95 a p99 latence, TTFB, slow query log, stav PHP-FPM poolu a počet aktivních databázových spojení pod reálnou zátěží. Až podle dat určíme, který zásah přinese největší efekt za nejmenší riziko.

Databáze

  • Analýza slow query logu a EXPLAIN plánů
  • Doplnění chybějících indexů a oprava N+1 dotazů
  • Ladění MySQL/MariaDB — buffer pool, connection limity
  • Odstranění full table scanů v kritických dotazech

Aplikace a PHP-FPM

  • Konfigurace PHP-FPM poolu — pm.max_children, timeouty
  • OPcache a preloading pro nižší režii interpretu
  • Profilace PHP a odstranění nejdražších míst v kódu
  • Přesun těžkých operací mimo HTTP request

Cache

  • Redis jako object a session cache
  • Full-page cache pro anonymní návštěvníky
  • Query cache a cache nákladných výpočtů
  • Cache na hraně sítě (CDN) pro statický obsah

perf.log · před → po

slow-qWARNquery 2.4s · missing index · products
fpmWARNpool busy · 32/32 workers · queue 12
cacheWARNOPcache hit rate 34 %
fixOK index added · 2.4s → 18ms
fixOK fpm pool 64 workers · queue 0
fixOK OPcache hit rate 94 %

Před většími akcemi nabízíme zátěžové testování, které odhalí limity dřív, než je objeví zákazníci. Víme tak předem, kolik objednávek za minutu e-shop ustojí a kde je první slabé místo. Každý zásah je vratný a nasazujeme ho s rollback plánem, aby optimalizace výkonu nikdy neohrozila samotný provoz.

Co optimalizací výkonu získáte

  • Rychlejší načítání a vyšší konverzní poměr
  • Stabilní e-shop i ve špičkách a při výprodejích
  • Nižší zatížení serveru a úspora za hardware
  • Lepší Core Web Vitals a pozice ve vyhledávání
  • Rychlejší administrace, importy a exporty
  • Měřitelný výsledek doložený čísly před a po
  • FAQ k výkonu e-shopu

    Proč je můj e-shop pomalý, když mám výkonný server?
    Pomalý e-shop málokdy způsobuje slabý hardware. Ve většině případů jde o databázové bottlenecky — chybějící indexy, N+1 dotazy nebo full table scany — a o špatně nastavený PHP-FPM či chybějící cache. Výkonný server tyto problémy jen oddálí, neodstraní. Proto začínáme měřením, ne nákupem většího stroje.
    Jak poznáte, kde přesně je problém s výkonem?
    Zapneme slow query log, analyzujeme p95 a p99 latence, profilujeme PHP a sledujeme stav PHP-FPM poolu a databázových spojení pod reálnou zátěží. Každé doporučení podkládáme konkrétním číslem — kterému dotazu chybí index, kolik workerů je obsazeno, jaký je hit rate cache.
    Zrychlí optimalizace e-shop i ve špičkách a při výprodejích?
    Ano, to je hlavní cíl. Optimalizujeme tak, aby e-shop ustál nárazové špičky při slevových akcích a výprodejích — kdy běžně padá. Součástí bývá zátěžové testování před kritickou akcí, abychom limity znali předem, ne až ve chvíli, kdy přijdou objednávky.
    Musíme kvůli optimalizaci přepisovat celý e-shop?
    Ne. Většinu výkonových problémů řeší cílené zásahy — doplnění indexů, oprava nejhorších dotazů, nasazení cache a správné nastavení PHP-FPM. K refaktoringu kódu sahneme jen tam, kde dává měřitelný smysl, a vždy s rollback plánem.
    Jak rychle se výsledek projeví?
    Nejčastější bottlenecky — chybějící index nebo špatně nastavený OPcache — mají dopad okamžitě po nasazení. Komplexnější ladění cache a front probíhá v řádu dní. Vždy nejprve měříme výchozí stav, takže zlepšení je doložitelné čísly.

    Zrychlíme váš e-shop měřitelně

    Napište, co vás brzdí. Změříme výchozí stav, najdeme bottlenecky a navrhneme konkrétní kroky k vyššímu výkonu.

    reakce do 24 h · pracovní dny NDA na vyžádání akutní incident · 24/7