Ile faktycznie zyskuje sklep po przejściu z Lumy na Hyvä?
Na standardowym motywie Luma w Magento 2.4.7 z kilkunastoma modułami komercyjnymi wynik Google Lighthouse dla urządzeń mobilnych rzadko przekracza 35 punktów, a Interaction to Next Paint (INP) regularnie przebija 450 ms. Po wdrożeniu Hyva Theme dla Magento ten sam sklep na procesorze AMD EPYC z PHP 8.3 i OpenSearch 2.12 osiąga powtarzalne 91-96 punktów na mobile, a INP spada poniżej 65 ms. Różnica nie wynika z agresywnego cache'owania, tylko z całkowitego usunięcia 200 żądań HTTP generowanych przez przestarzały stos RequireJS, Knockout.js i jQuery UI.
Przeanalizowaliśmy twarde dane z audytów sklepu z branży automotive (baza: 65 000 SKU, warianty konfigurowalne, integracja z Subiekt GT i Baselinkerem do Allegro). Oto pomiary na profilu Moto G4 (emulowane 4G, throttling CPU x4):
- Lighthouse Performance (Mobile): Luma 31/100 vs Hyvä 94/100
- First Contentful Paint (FCP): Luma 2,8 s vs Hyvä 0,8 s
- Largest Contentful Paint (LCP): Luma 5,4 s vs Hyvä 1,6 s
- Total Blocking Time (TBT): Luma 1 420 ms vs Hyvä 40 ms
- Interaction to Next Paint (INP): Luma 480 ms vs Hyvä 52 ms
- Waga pobieranego JavaScriptu: Luma 2,4 MB (nieskompresowany ~8 MB) vs Hyvä 78 kB
Luma zmusza przeglądarkę telefonu do sparsowania setek powiązanych ze sobą plików JS zanim użytkownik w ogóle kliknie przycisk „Dodaj do koszyka”. Hyvä opiera się na mikroskopijnym Alpine.js (ok. 15 kB) oraz klasach narzędziowych Tailwind CSS generowanych przez proces JIT w trakcie budowania layoutu.
Dlaczego wskaźnik INP na Lumie rujnuje konwersję na urządzeniach mobilnych?
Od marca 2024 roku wskaźnik INP zastąpił First Input Delay (FID) w raportach Core Web Vitals. O ile FID mierzył tylko pierwsze opóźnienie, o tyle INP sprawdza czas reakcji interfejsu na każde kliknięcie, tapnięcie czy naciśnięcie klawisza podczas całej sesji zakupowej. Jeśli klient klika filtr na liście produktów (PLP), a główny wątek procesora w telefonie jest zablokowany przez inicjalizację widgetów Knockout.js z modułu Mirasvit Layered Navigation czy Amasty Shop by Category, ekran zamarza na pół sekundy. W skrajnych przypadkach w konsoli ląduje ostrzeżenie: [Violation] 'click' handler took 382ms.
U nas w projektach widzimy powtarzalny schemat: Luma nie potrafi zwolnić wątku głównego, ponieważ UI Components w Magento 2 wykonują asynchroniczny parsing szablonów XML i x-magento-init w locie. Przeglądarka zamiast renderować natychmiastowy feedback (np. stan wciśnięcia przycisku lub loader), mieli drzewo DOM i zależności RequireJS.
Hyvä eliminuje ten problem architektonicznie. Alpine.js działa bezpośrednio w warstwie HTML jako reaktywne dyrektywyx-datai@click. Kiedy klient wybiera rozmiar lub kolor na karcie produktu, stan zmienia się synchronicznie w czasie poniżej 16 ms (jedna klatka przy 60 fps). Z punktu widzenia Core Web Vitals przeglądarka raportuje stan zielony.
Co dzieje się z modułami pod polski rynek: InPost, Przelewy24, Subiekt i KSeF?
Największa obawa właścicieli sklepów dotyczy kompatybilności polskich wtyczek. Magento na Lumie żyje dzięki modułom instalowanym przez Composera. Hyvä odrzuca cały frontend Lumy, co oznacza, że żaden moduł zawierający szablony .phtml z RequireJS i Knockoutem nie zadziała od razu.
Jak wygląda realna sytuacja na rynku w 2024 roku?
- Płatności (Przelewy24, PayU, BLIK): Oficjalne moduły płatności dostarczają już paczki kompatybilności
hyva-themes/magento2-theme-modulelub gotowe integracje checkoutu. Płatność natywnym BLIK-iem (0-step) w Hyvä Checkout lub Mageworx One Step Checkout działa bez zacięć. - Wysyłka (InPost Paczkomaty): Geowidget InPost wymagał w przeszłości ręcznego przepisania. Obecnie społeczność skupiona wokół Hyvä udostępnia przetestowane moduły kompatybilności, które ładują mapę punktów odbioru bez ładowania bibliotek jQuery UI.
- Systemy ERP (Subiekt GT/nexo, Comarch ERP Optima): Te integracje działają w 99% na poziomie backendu — przez REST/GraphQL API, bazy danych lub dedykowane konektory wymieniające stany magazynowe, ceny, białą listę VAT czy obsługę JPK_V7 i Krajowego Systemu e-Faktur (KSeF). Zmiana frontendu na Hyvä nie wpływa na logikę backendową tych mostów. Zlecenia
bin/magento setup:di:compilewykonują się bez kolizji w kodzie PHP. - Integratory typu Baselinker / Allegro: Działają wyłącznie po API Magento. Frontend jest dla nich całkowicie niewidoczny.
Ile kosztuje licencja, a ile wdrożenie Hyvä w polskich realiach?
Przejdźmy do twardych kwot. Koszt licencji Hyvä Themes to wydatek 1 000 EUR (opłata jednorazowa za nielimitowaną liczbę domen w obrębie jednej instalacji Magento 2). Opcjonalny Hyvä Checkout to kolejne 1 000 EUR (lub 250 EUR/rok w modelu subskrypcyjnym po pierwszym roku, zależnie od wybranego planu). Nie są to kwoty, które rujnują budżet średniej wielkości e-commerce generującego 200–500 tys. PLN obrotu miesięcznie.
Prawdziwym kosztem jest wdrożenie programistyczne. Jeśli sklep posiada:
- Standardowy zestaw modułów (blog, zaawansowane filtry, integracje kurierskie, płatności),
- Customowy design z Figmy przygotowany pod system komponentów Tailwind CSS,
- Brak skrajnie egzotycznych wtyczek sprzed 6 lat, do których nikt nie ma kodu źródłowego,
to czas wdrożenia zamyka się zazwyczaj w przedziale od 120 do 220 roboczogodzin. W SISL unikamy przepisywania kodu na siłę: jeśli moduł marketingowy zewnętrznego dostawcy nie ma paczki kompatybilności (Hyvä Compatibility Module), często taniej jest napisać prosty komponent w czystym Alpine.js pobierający dane z GraphQL, niż walczyć z debugowaniem pozostałości po starym RequireJS.
Czy da się uratować Lumę modułami optymalizującymi bez zmiany motywu?
Krótka odpowiedź: nie na mobile. Długa odpowiedź: można wydać 300-500 EUR na moduły typu Amasty Google Page Speed Optimizer, Mirasvit Fast As Fuck czy Breeze od SwissupLabs. Następnie spędzić 40 godzin na konfiguracji łańcuchów krytycznego CSS i odraczania skryptów JS.
Efekt? Na desktopie wynik w Lighthouse podskoczy do 80-85 punktów, ponieważ nowoczesny procesor Intela lub Apple M-series bez problemu przełknie 2 megabajty skryptów. Na telefonie ze średniej półki wskaźnik Total Blocking Time nadal będzie świecił na czerwono. Dlaczego? Ponieważ mechanizm defer dla RequireJS w Lumie często psuje kolejność inicjalizacji obiektów globalnych, generując w konsoli błędy typu Uncaught TypeError: mageSetup is not a function lub wyłączając walidację pól formularza w koszyku.
Pudrowanie Lumy to walka z długiem technologicznym z 2015 roku. Hyvä wyrzuca cały ten balast do kosza. Budowanie frontendu w oparciu o tailwind.config.js i kompilację przez npm run build sprawia, że plik produkcyjny CSS ma często poniżej 20 kB, a kod JS ładuje się wyłącznie tam, gdzie jest faktyczna interakcja.
Podsumowanie: kiedy migracja na Hyvä zwraca się najszybciej?
Inwestycja w Hyvä ma natychmiastowe uzasadnienie ekonomiczne w trzech przypadkach:
- Ruch w sklepie w co najmniej 65% pochodzi z urządzeń mobilnych (social ads, Google Ads, kampanie Performance Max), a wskaźnik odrzuceń na kartach produktów przekracza 50%.
- Sklep planuje migrację z Magento 2.3/2.4.3 na najnowszą wersję 2.4.7 z PHP 8.3 — wtedy koszt wdrożenia nowego frontu łączy się z naturalnym upgradem platformy.
- Koszty utrzymania serwera dedykowanego rosną, bo Luma wymaga gigantycznych zasobów CPU do obsługi jednoczesnych niescache'owanych zapytań generowanych przez klienta w koszyku.
Jeśli Twój sklep na Magento traci klientów na etapie wyboru wariantów lub przejścia do kasy z powodu lagów interfejsu, napisz do nas. Przeanalizujemy Twój obecny profil modułów, sprawdzimy listę kompatybilności i wskażemy, które elementy systemu wymagają przepisania, a które zadziałają z Hyvä od pierwszego uruchomienia bin/magento setup:upgrade.