Hyvä vs. Luma v číslech

Každá debata o výkonu Magenta dříve nebo později dorazí ke stejné otázce: je problém ve frontendu a je odpovědí Hyvä? Na obojí zní poctivá odpověď „většinou ano“. Pořád se ji ale vyplatí ověřit na vlastním e-shopu, místo abyste ji brali na slovo od nás nebo od kohokoli, kdo vám prodává přestavbu. Tento článek vysvětluje, v čem se oba frontendy strukturálně liší a jak si rozdíl změřit dříve, než do něj dáte peníze.

Proč je Luma pomalá už ze své podstaty

Luma, výchozí frontend Magenta, je pomalá kvůli rozhodnutím pevně zabudovaným do platformy kolem roku 2015:

RequireJS načítá JavaScript v řetězci závislostí, jednu po druhé. Prohlížeč zjistí, co má stáhnout dál, teprve když vykoná to, co už stáhl. Na mobilním připojení s vysokou latencí to znamená jeden round-trip za druhým, než stránka začne reagovat.
Na každou stránku se najednou načte několik těžkých JS vrstev. jQuery, KnockoutJS a vrstva UI komponent Magenta postavená na Knockoutu se načtou vždy, ať je stránka potřebuje, nebo ne.
Layout XML vykresluje více, než je potřeba. Bloky, které nikdo neuvidí, se stejně sestaví, a rozšíření třetích stran registrují své skripty globálně, a ne tam, kde jsou skutečně potřeba.

V profileru se nic z toho neukáže jako jeden pomalý řádek, zato se to ukáže jako megabajty JavaScriptu a hlavní vlákno vytížené několik sekund na telefonech střední třídy, které vaši zákazníci používají.

Co Hyvä skutečně mění

Hyvä je náhradní theme. Frontendový stack Lumy odstraňuje celý: žádný RequireJS, žádné jQuery, žádný Knockout. Šablony jsou serverově renderované PHP s Alpine.js pro interaktivitu a Tailwindem pro styly. Podle našich vlastních měření obvykle JavaScript klesne z něčeho přes megabajt na výrazně pod sto kilobajtů, což si sami ověříte v síťovém panelu libovolného prohlížeče na demo obchodě.

Kompromis: každé rozšíření, které sahá na frontend, potřebuje modul kompatibilní s Hyvä, nebo přepsání. U populárních rozšíření je kompatibilita vyřešena, u starších rozšíření na míru často neexistuje. Většinu nákladů projektu s Hyvä tvoří audit rozšíření.

Pokladna je samostatné rozhodnutí. Instalace Hyvä ve výchozím stavu ponechává pokladnu z Lumy přes Luma theme fallback, Hyvä Checkout je samostatný produkt (dokumentace Hyvä, ověřeno 22. července 2026). Právě pokladna přitom často rozhoduje o konverzích.

Jak si to změřit sami

Neporovnávejte svůj produkční e-shop s demem Hyvä; smícháte tak theme, katalog, hosting a skripty třetích stran. Férové srovnání vypadá takto:

Vyjděte z reálných dat od návštěvníků, ne jen z Lighthouse. CrUX (přes PageSpeed Insights) ukazuje, co skuteční návštěvníci zažili za 28 dní: LCP, INP, CLS. Laboratorní měření bez throttlingu na rychlém vývojářském stroji může vypadat mnohem lépe než to, co dostanou skuteční návštěvníci na telefonech střední třídy.
Oddělte frontend od backendu. TTFB určuje hlavně backend a síť (server, DNS, TLS); při TTFB 1,5 s to výměna theme nespraví. Většinu toho, co se děje po TTFB, dokáže výměna frontendu ovlivnit; pomalý backend nebo síť potřebují vlastní opravu.
Postavte srovnání poctivě. Stejný server, stejný katalog, stejná zapnutá rozšíření, tagy třetích stran buď zapnuté v obou, nebo vypnuté v obou. Lighthouse spusťte několikrát a porovnejte mediány, protože jednotlivé běhy jsou šum.
Sledujte vedle toho byznysovou metriku. Zaznamenejte konverzi podle třídy zařízení před a po a projekt posuzujte podle ní, ne podle skóre v Lighthouse.

Kdy odpověď není Hyvä

Hyvä je naše výchozí doporučení pro e-shopy na Lumě s výkonnostním problémem, ale ne pro každý e-shop. E-shop se čtyřsekundovým TTFB má problém v backendu. E-shop, který už běží na PWA Studio, čelí jiným kompromisům. A e-shop před replatformingem by neměl investovat ani do jednoho; napřed je na místě otázka replatforming, nebo oprava.

Pokud chcete měření nechat na nás, přesně toto je náš audit výkonu: rozdělení frontend/backend, audit rozšíření a seznam oprav seřazený podle priorit. A také tak začíná většina naší práce na Magentu.