Hyvä vs. Luma v číslech

Každá debata o výkonu Magenta dřív nebo později dorazí ke stejné otázce: je problém ve frontendu a je odpovědí Hyvä? Poctivá odpověď zní „většinou a většinou“, ale neměli byste ji brát od nás ani od nikoho, 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 na vlastním e-shopu dřív, než do něj dáte peníze.

Proč je Luma pomalá už z návrhu

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

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

Nic z toho se v profileru neukáže jako jeden pomalý řádek. Ukáže se to jako megabajty JavaScriptu a hlavní vlákno vytížené na několik sekund na telefonech střední třídy, tedy přesně tam, kde jsou vaši zákazníci.

Co Hyvä skutečně mění

Hyvä je náhradní theme, které frontendový stack Lumy nahrazuje 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ě.

Jedno omezení to má: každé rozšíření, které sahá na frontend, potřebuje modul kompatibilní s Hyvä, nebo přepsání. Ekosystém kompatibility je u populárních rozšíření zralý a u toho jednoho modulu na míru z roku 2019 prázdný. Skutečné náklady projektu s Hyvä leží v auditu rozšíření, ne v licenci theme.

Pokladna je samostatné rozhodnutí: Hyvä ve výchozím stavu ponechává pokladnu z Lumy, dokud nenasadíte Hyvä Checkout nebo headless řešení, a přitom právě pokladna č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á takhle:

Vyjděte z terénních dat, 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. Neškrcený laboratorní běh 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 vás žádný theme nezachrání. Většina toho, co se děje za TTFB, je prostor, který výměna frontendu dokáže ovlivnit; pomalý backend nebo síť si žádají 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 pusťte několikrát a porovnejte mediány, protože jednotlivé běhy jsou šum.
Sledujte vedle toho byznysovou metriku. Konverze podle třídy zařízení, před a po. To je číslo, které projekt obhajuje.

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 s TTFB čtyři sekundy má problém v backendu. E-shop, který už běží na PWA Studio, naráží na jinou hranici. 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ě tohle 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.