Zo 49 sekúnd na 3: čo brzdilo e-shop s 900 produktmi
E-shop fungoval a predával. Zákazníci nakupovali, objednávky chodili. Lenže keď majiteľ otvoril v administrácii jeden produkt, čakal 49 sekúnd. A databáza e-shopu s približne 900 produktmi mala 20 GB.
Klienta nemenujem. Je to slovenský e-shop s približne 900 produktmi, napojený na dodávateľa, na WordPresse a WooCommerce. Nerobil som ho. Prevzal som ho v januári 2026 a odvtedy sa oň starám.
V akom stave som ho prevzal
- Približne 70 pluginov, k tomu staršie kúsky vlastného kódu. Časť funkcií bola zbytočná alebo sa opakovala.
- Chýbajúca alebo nedostatočná cache. Web skladal tie isté stránky a údaje stále odznova.
- Web pre zákazníka sa načítaval približne 15 sekúnd.
- Admin rozhranie približne 49 sekúnd. A to bol jeden produkt.
- Databáza mala približne 20 GB, pri iba 900 produktoch.
- Domovská stránka načítavala 221 súborov a služieb: skripty, štýly, obrázky aj externé integrácie.
- Hosting hlásil preťaženie a ponúkal väčší výkon.
Pri 49 sekundách na každé otvorenie sa produkty a objednávky nedali normálne spravovať. Pluginy, importy od dodávateľa a cache sa navzájom ovplyvňovali tak, že nebolo jasné, čo za čo môže.
Čo som zistil
Databáza je sklad e-shopu. Sú v nej produkty, objednávky, zákazníci aj nastavenia. Lenže 900 produktov a ich objednávky 20 GB nevysvetľujú. Väčšinu skladu nezaberal tovar, ale prevádzkové záznamy.
Hlavná príčina: e-shop si zapisoval záznamy o svojich plánovaných úlohách, teda o práci, ktorú robí na pozadí. Takých záznamov sa nahromadilo vyše 100 miliónov. Veľká časť sa opakovala dookola. Web robil tú istú prácu stále znova a každý raz si to poctivo zapísal.
K tomu priveľa pluginov bez cache. Každá stránka sa skladala odznova a každý plugin pridal vlastnú prácu.
Prvý pokus nepomohol
Prvý pokus obmedziť zapisovanie doplnkovým kódom nefungoval. Záznamy pribúdali ďalej. Nebola to oprava na jeden klik.
Preto som postupoval od začiatku. Najprv som zistil, ktoré časti databázy rastú. Potom som oddelil to, čo e-shop naozaj potrebuje, teda produkty a objednávky, od prevádzkového balastu a databázu vyčistil. A hlavne som hľadal procesy, ktoré ju znova zapĺňali. Keby som len zmazal staré záznamy, o pár mesiacov by bol sklad plný znova.
Pridal som cache, aby sa ten istý obsah a tie isté údaje negenerovali stále dookola. Aj tá si vyžiadala ladenie: nesmela prekážať prihláseniu do administrácie ani importom od dodávateľa. Plánované úlohy dnes nespúšťajú návštevníci webu, ale server.
Výsledok
| Čo sa meralo | Predtým | Potom |
|---|---|---|
| Web pre zákazníka | približne 15 s | približne 2 s |
| Admin rozhranie | približne 49 s | 3 s |
| Databáza | približne 20 GB | približne 1,5 GB |
Čas v admine je konkrétne merané načítanie, nie všetky stránky e-shopu. Aj tak je to rozdiel medzi prácou, ktorá sa nedá robiť, a bežnou prácou.
Čo sa ukázalo počas správy
Zrýchlením sa práca neskončila. E-shop napojený na dodávateľa, platby, dopravu a marketingové služby má veľa miest, kde sa niečo môže pokaziť. Počas správy sa ukázali tieto:
Preťažený server (júl). Hosting opakovane hlásil, že web vyčerpal svoje limity. Príčinou bolo zobrazovanie produktov s desiatkami variantov, pri ktorých jedna požiadavka trvala 8 až 10 sekúnd. Keď prišlo naraz viac návštevníkov, zablokovali server. Zdroje záťaže som našiel a upravil, kedy sa tieto náročné požiadavky spúšťajú.
Rozpadnutý vzhľad (august). Stránka sa občas vizuálne rozpadla, a to v každom prehliadači. Chýbali súbory so štýlmi, ktoré si web generuje sám. Štýly som pregeneroval a cache vyčistil.
Výpadok dodávateľa (september). Feed od dodávateľa začal namiesto produktov vracať chybu. Problém bol na strane dodávateľa. Po jeho výpadku som v októbri import opravil a znova beží. Viac o importoch v článku Ako napojiť e-shop na dodávateľa.
Nechodiace e-maily (október). Majiteľovi nechodili niektoré upozornenia na objednávky, resety hesla a občas správy z formulárov. Problém som rozdelil na tri otázky: vytvoril e-shop správu? Prijala ju odosielacia služba? Prijal ju server príjemcu? Nastavenia SPF, DKIM a DMARC boli v poriadku, no prijímajúci server správy odmietal ako možný spam. Samotné povolenie odosielateľa nepomohlo. Potom som odosielanie prepol na SMTP a dve skúšobné objednávky, jedna na schránku u hostingu a jedna na Gmail, dorazili okamžite. Viac v článku Prečo zákazníkom nechodia e-maily z e-shopu.
Ako to vyzerá dnes
E-shop mám v mesačnej správe. Robím aktualizácie WordPressu a pluginov a po zásahoch kontrolujem, či všetko funguje. Sledujem výkon a databázu, aby sa znova nezaplnila, a strážim plánované úlohy aj importy od dodávateľa. Keď vypadne niektorá externá služba, riešim to s jej podporou. Majiteľ každý mesiac dostane report s dátami z Google Analytics.
Čo si z toho zobrať
- Pred väčším hostingom zistite, čo web robí. Hosting tu ponúkal väčší výkon, no príčina bola vo webe. Viac v článku Potrebujem drahší hosting, alebo stačí oprava?
- Rýchla záplata nestačí. Kým nenájdete, čo problém znova vytvára, vráti sa. Prečo sa e-shopy časom spomaľujú, vysvetľujem v článku Prečo sa e-shop časom spomaľuje.
- Odoslané neznamená doručené. To, že e-shop e-mail odoslal, ešte neznamená, že ho zákazník dostal.
Ak je aj váš e-shop pomalý, pozrite si zrýchlenie a opravy.