Hyvä vs. Luma, odmerané

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ä? Úprimná odpoveď znie „väčšinou a väčšinou“, ale nemali by ste ju brať od nás ani od nikoho, kto vám predáva prestavbu. Tento text vysvetľuje, čo je medzi oboma frontendmi štrukturálne inak a ako si rozdiel odmerať na vlastnom e-shope skôr, než doň vložíte peniaze.

Prečo je Luma pomalá zo samej podstaty

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

RequireJS načítava JavaScript ako vodopád závislostí. Prehliadač zistí, čo má stiahnuť ďalej, až keď vykoná to, čo už stiahol. Na studenom mobilnom pripojení to znamená opakované round-tripy, kým sa stránka stane interaktívnou.
Naraz sa posiela viacero ť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 renderuje nadbytočne. 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.

Nič z toho sa v profileri neukáže ako jeden pomalý riadok. Ukáže sa to ako megabajty JavaScriptu a hlavné vlákno zamestnané celé sekundy na stredne výkonných telefónoch, aké má väčšina vašich zákazníkov.

Čo Hyvä v skutočnosti mení

Hyvä je kompletná náhradná téma. Frontendový stack Lumy zahadzuje: ž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.

Obmedzením je kompatibilita rozšírení: každé rozšírenie, ktoré sa dotýka frontendu, potrebuje Hyvä-kompatibilný modul alebo prepis. Ekosystém kompatibility je pri populárnych rozšíreniach zrelý a pri tom jednom module na mieru z roku 2019 prázdny. Skutočné náklady Hyvä projektu sa skrývajú v audite rozšírení, nie v licencii témy.

Pokladňa je samostatné rozhodnutie: Hyvä v základe ponecháva pokladňu z Lumy, kým neprejdete na Hyvä Checkout alebo headless riešenie, a práve v pokladni sa často rozhoduje o konverziách.

Ako si to odmerať sami

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

Základňu berte z dát z reálnej prevádzky (field data), nie iba z Lighthouse. CrUX (cez PageSpeed Insights) ukazuje, čo reálni návštevníci zažili za 28 dní: LCP, INP, CLS. Neobmedzené laboratórne meranie 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.
Oddeľte frontend od backendu. TTFB ovláda backend a sieť (server, DNS, TLS); ak je TTFB 1,5 s, žiadna téma vás nezachráni. Väčšina toho, čo sa deje po TTFB, je to, čo vie výmena frontendu ovplyvniť; pomalý backend alebo sieť si žiadajú vlastnú opravu.
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).
Popri tom sledujte biznisovú metriku. Konverzie podľa triedy zariadenia, pred a po. Skóre samo o sebe nebolo cieľom projektu; konverzia je to číslo, ktoré projekt obhajuje.

Kedy odpoveď nie je Hyvä

Hyvä e-shopom na Lume s problémom výkonu odporúčame ako prvú voľbu, nie však automaticky. E-shop so 4-sekundovým TTFB má problém v backende a e-shopu, ktorý už beží na PWA Studio, sa počíta úplne iná matematika. A ak uvažujete o replatformingu, neinvestujte zatiaľ ani do jedného; najprv si zodpovedzte otázku 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.