Hyvä kontra Luma, na liczbach

Każda rozmowa o wydajności Magento kończy się tym samym pytaniem: czy problemem jest frontend i czy odpowiedzią jest Hyvä? Uczciwa odpowiedź brzmi „zwykle tak i zwykle tak”, ale nie musisz wierzyć na słowo ani nam, ani nikomu, kto sprzedaje Ci przebudowę. Ten tekst tłumaczy, czym strukturalnie różnią się oba frontendy i jak zmierzyć tę różnicę na własnym sklepie, zanim wydasz na nią pieniądze.

Dlaczego Luma jest wolna z założenia

Luma, domyślny frontend Magento, jest wolna przez decyzje wpisane w nią około 2015 roku:

RequireJS ładuje JavaScript kaskadą zależności. Przeglądarka dowiaduje się, co pobrać dalej, dopiero po wykonaniu tego, co już pobrała. Na zimnym łączu mobilnym oznacza to kolejne rundy w obie strony, zanim strona zacznie reagować.
Wiele ciężkich warstw JS ładuje się równocześnie. jQuery, KnockoutJS i oparta na Knockoucie warstwa UI komponentów Magento są obecne na każdej stronie, niezależnie od tego, czy strona z nich korzysta.
Layout XML renderuje więcej, niż trzeba. Bloki, których nikt nie widzi, i tak się budują, a rozszerzenia firm trzecich dołączają swoje skrypty globalnie, a nie tam, gdzie są potrzebne.

Nic z tego nie pokazuje się w profilerze jako pojedyncze wolne wywołanie. Pokazuje się jako megabajty JavaScriptu i główny wątek zajęty przez całe sekundy na średniej klasy telefonach, czyli tam, gdzie są Twoi klienci.

Co Hyvä naprawdę zmienia

Hyvä to motyw zastępczy, nie doraźna poprawka. Usuwa stos frontendowy Lumy w całości: bez RequireJS, bez jQuery, bez Knockouta. Szablony to PHP renderowane po stronie serwera, z Alpine.js do interaktywności i Tailwindem do styli. W naszych własnych pomiarach waga JavaScriptu spada zwykle z ponad megabajta do znacznie poniżej stu kilobajtów, co możesz sprawdzić samodzielnie w zakładce sieciowej dowolnej przeglądarki na sklepie demo.

Jest jednak istotne zastrzeżenie: każde rozszerzenie dotykające frontendu potrzebuje modułu zgodnego z Hyvä albo przepisania. Ekosystem kompatybilności jest dojrzały dla popularnych rozszerzeń, ale moduły pisane na zamówienie trzeba przejrzeć jeden po drugim. Prawdziwy koszt projektu Hyvä leży w audycie rozszerzeń, a nie w licencji motywu.

Checkout to osobna decyzja: Hyvä w wersji podstawowej zostaje przy checkoucie z Lumy, o ile nie sięgniesz po Hyvä Checkout albo rozwiązanie headless, a to właśnie checkout ma zwykle największy wpływ na konwersję.

Jak to zmierzyć samodzielnie

Nie porównuj swojego produkcyjnego sklepu z demem Hyvä; to miesza motyw, katalog, hosting i skrypty firm trzecich. Rzetelne porównanie wygląda tak:

Punkt wyjścia bierz z danych realnych użytkowników, nie tylko z Lighthouse. CrUX (przez PageSpeed Insights) pokazuje, czego odwiedzający doświadczyli przez 28 dni: LCP, INP, CLS. Test laboratoryjny bez throttlingu na szybkiej maszynie deweloperskiej potrafi wypaść znacznie lepiej niż to, co widzą realni odwiedzający na średniej klasy telefonach.
Oddziel frontend od backendu. TTFB zależy głównie od backendu i sieci (serwer, DNS, TLS); jeśli TTFB wynosi 1,5 s, wymiana motywu tego nie poprawi. Większość tego, co dzieje się po TTFB, to obszar, na który wymiana frontendu ma wpływ; wolny backend albo sieć wymagają własnej poprawki.
Wyrównaj warunki. Ten sam serwer, ten sam katalog, te same włączone rozszerzenia, tagi firm trzecich albo włączone w obu, albo wyłączone w obu. Lighthouse uruchom kilka razy i porównuj mediany; pojedyncze przebiegi to szum.
Śledź obok metrykę biznesową. Konwersja w podziale na klasy urządzeń, przed i po. To liczba, która uzasadnia projekt.

Kiedy odpowiedzią nie jest Hyvä

Hyvä to nasza domyślna rekomendacja dla sklepów na Lumie z problemem wydajności, choć nie rekomendujemy jej bez pomiarów. Sklep z TTFB na poziomie 4 sekund ma problem z backendem. Sklep, który już stoi na PWA Studio, ma inną granicę możliwości. A sklep tuż przed replatformingiem nie powinien inwestować w żadne z tych rozwiązań; najpierw pytanie replatforming czy naprawa.

Jeśli chcesz, żeby ktoś wykonał te pomiary za Ciebie (z podziałem na frontend i backend, audytem rozszerzeń i listą poprawek według priorytetów), dokładnie tym jest nasz audyt wydajności. Tak też zaczyna się większość naszej pracy przy Magento.