Cacheovanie ako strategická zbraň e-shopu

Cacheovanie je pravdepodobne jedna z najefektívnejších optimalizácií výkonu e-shopu z hľadiska pomeru cena/výkon. Správne implementované cacheovanie dokáže znásobiť kapacitu vášho servera, dramaticky skrátiť časy načítania a znížiť náklady na infraštruktúru — bez zmeny samotného kódu. A predsa ju väčšina e-shopov implementuje iba povrchne, alebo nie správne.

V tomto článku si prejdeme cacheovanie od základov po pokročilé stratégie — s konkrétnymi odporúčaniami pre e-commerce kontexty.

Prečo je cacheovanie pre e-commerce kritické

E-shop má niekoľko charakteristík, ktoré robia cacheovanie obzvlášť cenným:

• Produktové stránky navštevuje tisíce zákazníkov, ale obsah sa mení len zriedka (keď sa zmení cena alebo zásoby)
• Kategóriové stránky sú rovnaké pre väčšinu návštevníkov
• Peak traffic (Black Friday, sezónne výpredaje) môže byť 10–100× väčší ako bežná prevádzka
• Konverzný pomer priamo závisí od rýchlosti — každá milisekunda sa počíta

Bez cacheovanie musí každý request generovať HTML od nuly — databázové dotazy, šablónovanie, agregácia dát. S cacheovaním väčšina requestov vráti predpripravený výsledok za zlomok milisekundy.

Vrstvy cacheovanie v modernom e-shope

1. CDN Cache (Edge Cache)

Prvá obranná línia. CDN servery cachujú statické súbory (obrázky, CSS, JS) a môžu cachovať aj celé HTML stránky. Requesty na cachovaný obsah nikdy nedosiahnu váš server — obslúži ich CDN edge server v blízkosti zákazníka.

Pre e-commerce: produktové stránky, ktoré sa nemenia alebo sa menia zriedka, sú ideálni kandidáti na CDN cache s dlhou TTL (Time-to-Live).

2. Application Cache (Server-side)

Na úrovni aplikácie môžete cachovať výsledky drahých operácií — komplexné databázové dotazy, agregácie, volania externých API. Redis je de facto štandard pre application cache v e-commerce.

Príklady:

• Výsledky fulltext vyhľadávania (rovnaký dopyt za posledných 5 minút)
• Agregované hodnotenia produktov
• Produktové odporúčania (netreba generovať pri každom requeste)
• Taxonómia a navigácia (mení sa iba pri editácii)

3. Database Query Cache

Databázy (PostgreSQL, MySQL) majú vlastné query cache mechanizmy. Správne indexy a optimalizované dotazy sú základom, ale pre časté, rovnaké dotazy môže byť database cache výraznou pomocou.

4. Browser Cache

Prostredníctvom HTTP hlavičiek (Cache-Control, ETag) inštruujete prehliadač zákazníka, čo môže cachovať a ako dlho. Obrázky, fonty a statické assety by mali mať dlhú TTL — zákazník ich nemusí sťahovať pri každej návšteve.

Cacheovanie v Next.js a headless architektúre

Headless architektúra, aká je použitá pri frontendoch pre platformu Grandus, prináša výnimočné možnosti pre cacheovanie na úrovni frameworku.

Next.js ponúka niekoľko cacheovacích stratégií:

• Static Site Generation (SSG) — stránky sa vygenerujú pri build čase a servírujú ako statické súbory. Žiadny server-side rendering pri každom requeste. Ideálne pre produktové stránky, ktoré sa menia zriedka.
• Incremental Static Regeneration (ISR) — stránky sú statické, ale automaticky sa regenerujú na pozadí po uplynutí TTL. Zákazník vždy dostane rýchlu statickú stránku, ale obsah je pravidelne aktualizovaný.
• On-Demand Revalidation — keď sa produkt v Grandus REST API zmení (cena, dostupnosť), pošle webhook, ktorý spustí regeneráciu iba tej konkrétnej stránky. Ostatné stránky zostávajú v cache nedotknuté.

Výsledok: produktové stránky sa servírujú zo statického cache (blazing fast), ale aktualizujú sa okamžite pri zmene dát.

Cache Invalidation: Najtažší problém cacheovania

Phil Karlton, legendárny počítačový vedec, povedal: „V computer science sú len dve ťažké veci: cache invalidation a pomenovanie vecí."

Cache invalidation je proces, pri ktorom označíte cachovaný obsah ako neplatný, keď sa zdrojové dáta zmenia. V e-commerce je toto kritické:

• Cena sa zmení → produktová stránka musí zobraziť novú cenu
• Produkt vypredaný → tlačidlo „Pridať do košíka" musí byť deaktivované
• Nová recenzia → hodnotenie musí byť aktualizované

Stratégie invalidácie:

• TTL-based — cache platí X minút, potom sa automaticky obnoví. Jednoduché, ale môže servírovať zastaralý obsah.
• Event-based — zmena v systéme triggeruje okamžitú invalidáciu konkrétnej cache. Komplexnejšie, ale vždy aktuálne.
• Surrogate keys / Cache tags — každý cachovaný objekt je označkovaný, invalidácia prebieha podľa tagov. Efektívne pre komplexné závislosti.

Čo nikdy necachovať

Rovnako dôležité ako vedieť, čo cachovať, je vedieť, čo nie:

• Obsah košíka — vždy unikátny pre zákazníka
• Checkout stránky — obsahujú citlivé dáta a musia byť vždy aktuálne
• Zákaznícky účet — osobné dáta nesmú byť cachované zdieľane
• Stránky po prihlásení — používajú session-specific dáta

Cachovaný košík jedného zákazníka zobrazený inému zákazníkovi je nielen bug, ale potenciálne aj bezpečnostný incident.

Praktické metriky a monitoring

Ako viete, že vaše cacheovanie funguje správne? Sledujte:

• Cache Hit Rate — percento requestov obslúžených z cache (cieľ: nad 90% pre statický obsah)
• Cache Miss Rate — requesty, ktoré museli ísť na origin server
• TTL vs. invalidácie — pomer plánovaných expirácií vs. manuálnych invalidácií
• Cache Size — rastúci cache môže signalizovať neefektívnu kľúčovaciu stratégiu

Záver: Cacheovanie ako architektonická disciplína

Cacheovanie nie je len technická optimalizácia. Je to architektonická disciplína, ktorá vyžaduje pochopenie biznis procesov, vzorcov zmien dát a zákazníckych potrieb. Dobre implementované cacheovanie je tichá, nenápadná výhoda — zákazník si nevšimne, že existuje, ale okamžite si všimne, keď chýba.

E-shopy, ktoré berú cacheovanie vážne, zvládajú Black Friday bez potenia. Tie, ktoré ho ignorujú, zistia limity svojej infraštruktúry práve vtedy, keď by mali predávať.