Hyvä dla Magento: kiedy przepisanie frontendu się zwraca
Migracja z Lumy na Hyvä to nie jest zmiana skórki, tylko przepisanie warstwy prezentacji razem z modułami. Kiedy to się opłaca, ile realnie kosztuje i kiedy lepiej tego nie robić.
Rozmowa zwykle zaczyna się tak samo. Sklep działa, sprzedaje, ale jest wolny, a ktoś proponuje przepisanie frontendu na Hyvä. Pytanie brzmi: czy to naprawdę konieczne, czy da się jeszcze coś wycisnąć z tego, co jest?
Ten tekst nie tłumaczy, czym jest Hyvä i dlaczego jest szybsza. To opisaliśmy osobno, razem z oceną pozostałych alternatyw dla frontendu Magento, w artykule Nasza droga do wydajnego frontendu Magento 2. Tutaj chodzi o decyzję: kiedy przepisanie się zwraca, co naprawdę kosztuje i kiedy odradzamy.
Luma nie jest porzucona. Jest zamrożona
Najczęstszy argument w tej dyskusji brzmi, że Luma stoi na nieaktualnych bibliotekach. W tej formie jest on nie do obrony i łatwo go obalić. Stan na 29 sierpnia 2026:
| Biblioteka | Wersja w Magento | Ostatnie wydanie |
|---|---|---|
| jQuery | 3.7.1 | bieżąca stabilna gałąź 3.x |
| Knockout | 3.5.3 | 25 marca 2026 |
| RequireJS | 2.3.8 | 30 listopada 2025 |
Żadne z tych repozytoriów nie jest zarchiwizowane i każde dostało łatkę w ciągu ostatniego roku. Kto mówi, że to martwe oprogramowanie, mija się z faktami.
Prawdziwy problem widać dopiero w odstępach między wydaniami. Knockout stoi na linii 3.5.x od lutego 2019, a między wersją 3.5.1 z listopada 2019 a 3.5.2 z marca 2026 minęło sześć lat i cztery miesiące bez żadnego wydania. RequireJS stoi na linii 2.3.x od 2017, a między 2.3.6 z 2018 a 2.3.7 z 2024 minęło prawie sześć lat. Obie biblioteki żyją na tyle, żeby dostać sporadyczną poprawkę, i żadna nie rozwija się projektowo.
To nie jest zarzut wobec ich autorów. To opis sytuacji, w której znajduje się sklep: ładowanie modułów AMD w przeglądarce i wiązania MVVM Knockouta to rozwiązania sprzed ery modułów ES i nowoczesnych bundlerów. Działają. Nikt nie zaczyna na nich nowego projektu.
I tu jest argument, który w praktyce waży najwięcej, a pada najrzadziej, bo nie jest techniczny. Coraz trudniej znaleźć frontendowca, który chce pracować w RequireJS i Knockoucie. Z każdym rokiem jest trudniej, a to przekłada się wprost na czas i koszt każdej kolejnej zmiany w sklepie. Hyvä stawia naprzeciw Tailwind CSS i Alpine.js, czyli narzędzia, które kandydat zna, zanim przyjdzie na rozmowę.
Jedno zastrzeżenie: wersja jQuery zależy od wersji Magento, na której stoi konkretny sklep. Powyższa tabela opisuje bieżącą gałąź rozwojową, a nie sklep sprzed czterech aktualizacji.
Kiedy optymalizowanie Lumy przestaje się zwracać
Przepisanie frontendu nie jest pierwszym krokiem i nie powinno być. Zanim ktokolwiek wyceni migrację, warto wyczerpać rzeczy tańsze, bo bardzo często to one dają większość efektu:
- obrazy w nowoczesnych formatach, z wymiarami i leniwym ładowaniem,
- pamięć podręczna po stronie serwera i CDN,
- czas odpowiedzi serwera, czyli TTFB,
- skrypty zewnętrzne, których na typowym sklepie jest kilkanaście i każdy jest czyjąś decyzją, nie awarią.
Jeśli po tych czterech krokach sklep nadal jest wolny, warto sprawdzić, gdzie idzie czas. Granica przebiega w jednym miejscu: dopóki wąskim gardłem są zasoby i serwer, przepisanie motywu niczego nie naprawi. Dopiero gdy problemem staje się to, ile kodu przeglądarka musi wykonać, zanim strona zacznie reagować, zmiana warstwy prezentacji jest właściwą odpowiedzią, bo to właśnie ona jest przyczyną.
Powiedzmy to wprost, bo oszczędza to nieporozumień na etapie oferty: jeśli Twoim problemem jest TTFB, Hyvä go nie rozwiąże.
Największym kosztem nie jest motyw, tylko moduły
Tu przepada większość budżetów w tego typu projektach i tu warto zadać pytanie, zanim padnie jakakolwiek kwota.
Hyvä nie renderuje szablonów Lumy. To nie jest nakładka na istniejący motyw, tylko osobna warstwa prezentacji. Każdy moduł, który ma własny frontend, a więc filtry, wyszukiwarka, konfigurator, program lojalnościowy, integracja z porównywarką, potrzebuje albo wersji zgodnej z Hyvä, albo przepisania.
Dlatego wycena migracji jest funkcją listy rozszerzeń, a nie wielkości katalogu ani liczby stron. Dwa sklepy o podobnym ruchu mogą różnić się kosztem kilkukrotnie, jeśli jeden ma pięć modułów z gotowym wsparciem, a drugi dwadzieścia, w tym trzy pisane kiedyś na zamówienie. Rzetelna oferta zaczyna się od przeglądu tej listy, a nie od liczby szablonów.
Dobra wiadomość jest taka, że ekosystem dojrzał: wielu dostawców publikuje dziś wersje zgodne z Hyvä, a dla części popularnych rozszerzeń istnieją gotowe moduły zgodności. Zła jest taka, że dotyczy to modułów popularnych. Rozszerzenie napisane pod konkretny sklep pięć lat temu trzeba przepisać i nikt tego nie zrobi za nas.
Hyvä Checkout to druga decyzja, nie część pierwszej
Warto wiedzieć, zanim wejdzie do wyceny jako oczywistość: checkout jest osobnym produktem, z osobnym zakresem prac. Można przejść na Hyvä i zostawić dotychczasowy proces zakupowy.
Jeśli jednak wchodzi, to on jest tym miejscem, gdzie zmiana dotyka konwersji bezpośrednio, a nie za pośrednictwem szybkości. W sklepie, który opisujemy niżej, checkout został wdrożony razem z motywem i widać na nim decyzje, które z frameworkiem nie mają nic wspólnego: zakup bez zakładania konta, z propozycją założenia go dopiero po złożeniu zamówienia, podsumowanie zamówienia widoczne przez cały czas oraz konkretny przedział daty dostawy zamiast ogólnikowego „3–5 dni roboczych”.
To jest właściwy sposób myślenia o tym etapie. Hyvä Checkout daje szybszy i prostszy proces, ale to, co w nim stoi, pozostaje decyzją sklepu.
Jak to wygląda na produkcji
Sprint Rowery przeszli z Lumy na Hyvä razem z Hyvä Checkout. Poniżej dane terenowe z raportu Chrome UX, czyli pomiary od prawdziwych użytkowników z okna 28 dni, a nie pojedynczy test laboratoryjny. Odczyt z 29 sierpnia 2026:
| Wskaźnik | Komórka | Stacjonarny | Próg „dobry” |
|---|---|---|---|
| LCP | 1,4 s | 1,1 s | do 2,5 s |
| INP | 179 ms | 78 ms | do 200 ms |
| CLS | 0,06 | 0,1 | do 0,1 |
| FCP | 0,7 s | 0,5 s | do 1,8 s |
| TTFB | 0,4 s | 0,3 s | do 0,8 s |
Ocena podstawowych wskaźników internetowych: zaliczone, na obu rodzajach urządzeń. Sklep na Magento z mobilnym LCP na poziomie 1,4 sekundy to wynik, którego ta platforma nie osiąga domyślnie. Każdy może to sprawdzić samodzielnie w PageSpeed Insights, wpisując adres sklepu.
Dwie rzeczy, o których trzeba powiedzieć uczciwie, bo inaczej ta tabela wprowadza w błąd.
W tym artykule nie podajemy wyników sprzed migracji. Powyższe liczby czytaj więc jako opis stanu, a nie jako miarę zmiany.
Jeden wskaźnik leży dokładnie na progu. CLS na komputerach stacjonarnych wynosi 0,1, a rozkład pokazuje, że część sesji ten próg przekracza. Wskazujemy to celowo, bo z tego wynika rzecz ważniejsza niż sam wynik: przesunięcia układu nie są własnością frameworka. Biorą się z tego, co i w jakiej kolejności ładuje strona, na przykład z banera nad nagłówkiem albo z widgetu wstrzykiwanego przez zewnętrzny skrypt. Żaden motyw tego za nikogo nie posprząta.
Drugim sklepem, który prowadzimy na Hyvä, jest Trefl. Nie podajemy dla niego wskaźników, ponieważ prace optymalizacyjne nie są tam zakończone, a pokazanie niedokończonego wyniku obok skończonego sugerowałoby porównanie, którego nie robimy.
Kiedy tego nie robić
Cztery sytuacje, w których odradzamy migrację, mimo że potrafilibyśmy ją wykonać:
- Sklep przed replatformingiem. Jeśli w perspektywie roku rozważana jest zmiana platformy, przepisywanie frontendu Magento jest inwestycją w coś, co i tak zostanie wyrzucone.
- Ciężki zestaw rozszerzeń bez wsparcia dla Hyvä. Kiedy większość kluczowych modułów wymaga przepisania, koszt przestaje odpowiadać korzyści, a ryzyko projektowe rośnie szybciej niż budżet.
- Wąskie gardło po stronie serwera. Wysoki TTFB, wolne zapytania, brak pamięci podręcznej. To jest inna praca i trzeba ją wykonać wcześniej, niezależnie od motywu.
- Brak zasobów po stronie sklepu. Migracja to nie tylko kod. Ktoś musi przetestować proces zakupowy, przejrzeć kategorie i zaakceptować zmiany. Jeśli nie ma kto, termin i tak się rozjedzie.
Podsumowanie
Przepisanie frontendu na Hyvä zwraca się wtedy, gdy tańsze optymalizacje są już wykorzystane, wąskim gardłem jest wykonywanie kodu w przeglądarce, a lista rozszerzeń nie zamienia projektu w przepisywanie całego sklepu. Wtedy efekt jest mierzalny i trwały, a przy okazji sklep wychodzi z technologii, w której coraz trudniej o ludzi.
Jeśli chcesz sprawdzić, po której stronie tej granicy jest Twój sklep, zacznij od przeglądu listy modułów i od pomiaru, gdzie faktycznie idzie czas. Zajmujemy się wdrożeniami i rozwojem Magento oraz wsparciem i aktualizacjami istniejących sklepów.
Ekspert frontendu, specjalizujący się w nowoczesnych technologiach webowych. W Macopedia odpowiada za optymalizację i rozwój aplikacji frontendowych, ze szczególnym uwzględnieniem modułu TYPO3 headless dla Nuxt. Pasjonat wydajności i najlepszych praktyk w budowie aplikacji webowych, stale eksplorujący nowe podejścia do optymalizacji kodu i poprawy doświadczeń użytkowników. W swoich artykułach dzieli się doświadczeniami dotyczącymi performance aplikacji.