Preskočiť na obsah
Zapolu

21. mája 2026, Luboš Zápotočný

Hyvä vs. Luma v číslach

Čo v skutočnosti brzdí Lumu, čo mení Hyvä a ako si rozdiel odmerať na vlastnom katalógu namiesto spoliehania sa na tvrdenia predajcu.

Každá debata o výkone Magenta skôr či neskôr dorazí k tej istej otázke: je problém vo frontende a je odpoveďou Hyvä? Na oboje znie poctivá odpoveď „väčšinou áno“. Stále sa ju však oplatí overiť na vlastnom e-shope, namiesto toho, aby ste ju brali na slovo od nás alebo od kohokoľvek, kto vám predáva prestavbu. Tento text vysvetľuje, čo je medzi oboma frontendmi štrukturálne inak a ako si rozdiel odmerať skôr, než doň vložíte peniaze.

Prečo je Luma pomalá zo samej podstaty

Luma, predvolený frontend Magenta, je pomalá pre rozhodnutia zabudované do platformy okolo roku 2015:

  • RequireJS načítava JavaScript v reťazci závislostí, jednu po druhej. Prehliadač zistí, čo má stiahnuť ďalej, až keď vykoná to, čo už stiahol. Na mobilnom pripojení s vysokou latenciou to znamená round-trip za round-tripom, kým sa stránka stane interaktívnou.
  • Na každú stránku sa naraz načíta niekoľko ťažkých JS vrstiev. jQuery, KnockoutJS a na Knockoute postavená vrstva UI komponentov Magenta prichádzajú na každú stránku bez ohľadu na to, či ich stránka používa.
  • Layout XML vykresľuje viac, než stránka potrebuje. Bloky, ktoré nikto neuvidí, sa aj tak postavia, a rozšírenia tretích strán pripájajú svoje skripty globálne namiesto tam, kde ich treba.

V profileri sa nič z toho neukáže ako jeden pomalý riadok, zato sa to ukáže ako megabajty JavaScriptu a hlavné vlákno zamestnané celé sekundy na stredne výkonných telefónoch, ktoré vaši zákazníci používajú.

Čo Hyvä v skutočnosti mení

Hyvä je náhradná šablóna. Frontendový stack Lumy odstraňuje celý: žiadny RequireJS, žiadne jQuery, žiadny Knockout. Šablóny sú serverovo renderované PHP s Alpine.js pre interaktivitu a Tailwindom pre štýly. Podľa našich vlastných meraní JavaScript zvyčajne klesne z niečoho nad megabajt na výrazne pod sto kilobajtov, čo si viete overiť sami v network tabe ľubovoľného prehliadača na demo obchode.

Kompromis: každé rozšírenie, ktoré sa dotýka frontendu, potrebuje Hyvä-kompatibilný modul alebo prepis. Pri populárnych rozšíreniach je ekosystém kompatibility zrelý, pri starších rozšíreniach na mieru často neexistuje. Väčšinu nákladov projektu s Hyvä tvorí audit rozšírení.

Pokladňa je samostatné rozhodnutie. Inštalácia Hyvä v základe ponecháva pokladňu z Lumy cez Luma theme fallback, Hyvä Checkout je samostatný produkt (dokumentácia Hyvä, overené 22. júla 2026). Práve v pokladni sa pritom často rozhoduje o konverziách.

Ako si to odmerať sami

Neporovnávajte svoj produkčný e-shop s demom Hyvä; zmiešali by ste šablónu, katalóg, hosting a skripty tretích strán. Férové porovnanie vyzerá takto:

  1. Východiskové čísla si vezmite z reálnej prevádzky (field data), nie len z Lighthouse. CrUX (cez PageSpeed Insights) ukazuje, čo reálni návštevníci zažili za 28 dní: LCP, INP, CLS. Laboratórny beh bez throttlingu na rýchlom vývojárskom stroji môže vyzerať oveľa lepšie než to, čo dostanú reálni návštevníci na stredne výkonných telefónoch.
  2. Oddeľte frontend od backendu. TTFB určuje najmä backend a sieť (server, DNS, TLS); ak je TTFB 1,5 s, výmena šablóny to nespraví. Väčšinu toho, čo sa deje po TTFB, dokáže výmena frontendu ovplyvniť; pomalý backend alebo sieť si žiadajú vlastnú opravu.
  3. Porovnanie pripravte poctivo. Rovnaký server, rovnaký katalóg, rovnaké zapnuté rozšírenia, tagy tretích strán buď zapnuté v oboch prípadoch, alebo vypnuté v oboch. Lighthouse spustite niekoľkokrát a porovnávajte mediány (jednotlivé behy sú šum).
  4. Popri tom sledujte obchodnú metriku. Zaznamenajte konverziu podľa triedy zariadenia pred a po a projekt posudzujte podľa nej, nie podľa skóre v Lighthouse.

Kedy odpoveď nie je Hyvä

Hyvä je naše predvolené odporúčanie pre e-shopy na Lume s problémom výkonu, ale nie pre každý e-shop. E-shop so 4-sekundovým TTFB má problém v backende. E-shop, ktorý už beží na PWA Studio, čelí iným kompromisom. A e-shop pred replatformingom by nemal investovať ani do jedného; najprv je na mieste otázka replatforming alebo oprava.

Ak chcete, aby meranie spravil niekto za vás (s rozdelením frontend/backend, auditom rozšírení a zoznamom opráv podľa priorít), presne to je náš audit výkonu. Takto začína aj väčšina našej práce s Magentom.