Hyva Theme a Core Web Vitals: czy warto migrować frontend Magento?
Table of Contents
20 punktów w PageSpeed to nie wynik. To diagnoza
Otwieram PageSpeed Insights, wklejam URL sklepu na Magento z motywem Luma, klikam “Analizuj”. Wynik na mobile: 24 punkty. Ładowanie: 6,3 sekundy. LCP: czerwone. INP: czerwone. Jedyny zielony element to CLS, bo strona ładuje się tak wolno, że nic nie zdąża się przesunąć.
To nie jest wyjątek. To norma. Magento 2 pod względem backendu i możliwości biznesowych nie ma sobie równych w swojej klasie. Problem w tym, że domyślny frontend, czyli motyw Luma, został zaprojektowany w 2015 roku i od tamtego czasu niewiele się zmienił. Luma ładuje 1-2 MB samego JavaScriptu, zanim przeglądarka w ogóle zacznie renderować to, co widzi użytkownik.
Hyva Theme to alternatywny frontend dla Magento 2, który rozwiązuje ten problem od podstaw. W tym artykule pokażę realne dane wydajnościowe i pomogę ocenić, czy migracja ma sens w Twoim przypadku.
Problem z motywem Luma
Żeby zrozumieć, dlaczego Hyva w ogóle powstała, trzeba przyjrzeć się architekturze Luma i zidentyfikować, co dokładnie powoduje problemy z wydajnością.
Przestarzały stos technologiczny
Luma opiera się na trzech bibliotekach JavaScript, które w 2026 roku są reliktem przeszłości:
- RequireJS jako moduł loader, który dodaje narzut przy każdym ładowaniu strony i komplikuje zarządzanie zależnościami
- KnockoutJS do renderowania dynamicznych komponentów (koszyk, checkout, filtry), który generuje ciężkie bindingi i wolno się inicjalizuje
- jQuery w wersji, która sama w sobie waży ponad 80 KB w wersji zminifikowanej
Do tego dochodzi jQuery UI, Require-text, i dziesiątki mniejszych zależności. Wynik? Typowa strona główna sklepu na Luma ładuje 1-2 MB samego JavaScriptu, zanim jeszcze weźmiemy pod uwagę CSS, obrazy i fonty.
Jak to przekłada się na metryki
W audytach sklepów Magento 2 z motywem Luma często widzimy profil wydajności w tym zakresie (mobile, połączenie 4G):
- LCP (Largest Contentful Paint): 4-8 sekund, przy progu Google na poziomie 2,5 sekundy
- INP (Interaction to Next Paint): 300-500 ms, przy progu Google na poziomie 200 ms
- CLS (Cumulative Layout Shift): 0.15-0.3, przy progu Google na poziomie 0.1
Każda z tych metryk wypada w strefie “poor” (czerwonej) lub co najwyżej “needs improvement” (pomarańczowej). W raporcie CrUX (Chrome User Experience Report), który Google wykorzystuje do oceny wydajności w kontekście rankingów, takie wyniki plasują sklep w dolnej części stawki.
Dlaczego standardowe optymalizacje nie wystarczają
Wielu właścicieli sklepów próbuje ratować wydajność Luma bez zmiany frontendu. Standardowe działania obejmują wdrożenie Varnish Cache, konfigurację Redis, optymalizację obrazów, lazy loading i minifikację CSS/JS.
Te optymalizacje pomagają, ale mają swój sufit. 25 punktów staje się 35-45. Nie da się jednak osiągnąć 80+ punktów, gdy fundamentalna architektura wymaga załadowania setek kilobajtów JavaScriptu do obsługi podstawowych interakcji. To jak próba przyspieszenia ciężarówki przez wymianę opon na lżejsze. Pomaga, ale problem leży w masie pojazdu, nie w oponach.
Co to jest Hyva Theme
Hyva to kompletny zamiennik warstwy frontendowej Magento 2. Nie jest to motyw potomny (child theme) oparty na Luma. To całkowicie nowa implementacja frontendu, która zachowuje pełną kompatybilność z backendem Magento, ale radykalnie zmienia sposób renderowania interfejsu.
Stos technologiczny Hyva
Zamiast RequireJS, KnockoutJS i jQuery, Hyva wykorzystuje:
- Alpine.js (ok. 15 KB) zamiast KnockoutJS + jQuery (ok. 300 KB). Alpine obsługuje interaktywne komponenty: koszyk, filtry, galerie, menu mobilne
- Tailwind CSS zamiast LESS/CSS Magento. Tailwind generuje tylko te klasy, które są faktycznie używane, co daje pliki CSS o rozmiarze 20-50 KB zamiast 200-400 KB
- Vanilla JavaScript tam, gdzie potrzebna jest dodatkowa logika, bez narzutu frameworka
Co to oznacza w praktyce
Typowa strona na Hyva ładuje 100-200 KB zasobów frontendowych (JS + CSS), w porównaniu do 1-2 MB na Luma. To redukcja o rząd wielkości. Mniejszy rozmiar to nie jedyna korzyść. Alpine.js inicjalizuje się w milisekundach, podczas gdy KnockoutJS z RequireJS potrzebuje setek milisekund na samo uruchomienie.
Porównanie wydajności: Luma vs Hyva
Poniżej przedstawiam dane z rzeczywistych migracji i benchmarków, a nie z laboratoryjnych testów na pustym sklepie. Wartości odnoszą się do urządzeń mobilnych, bo to one stanowią większość ruchu e-commerce i to na nich problemy wydajnościowe są najbardziej dotkliwe.
Core Web Vitals - porównanie
| Metryka | Luma (typowy sklep) | Hyva (typowy sklep) | Próg Google (“good”) |
|---|---|---|---|
| LCP | 4.5 - 8.0 s | 1.2 - 2.5 s | do 2.5 s |
| INP | 300 - 500 ms | 50 - 150 ms | do 200 ms |
| CLS | 0.15 - 0.30 | 0.01 - 0.05 | do 0.1 |
| PageSpeed (mobile) | 20 - 40 | 80 - 95 | n/d |
Rozmiar zasobów
| Zasób | Luma | Hyva |
|---|---|---|
| JavaScript | 800 KB - 1.5 MB | 50 - 120 KB |
| CSS | 200 - 400 KB | 20 - 50 KB |
| Liczba requestów (JS+CSS) | 30 - 60 | 5 - 15 |
| TTFB (z Varnish) | podobny | podobny |
Warto zauważyć, że TTFB (Time to First Byte) pozostaje porównywalny, bo zależy od backendu i konfiguracji serwerowej, a ta w obu przypadkach jest identyczna. Różnica tkwi wyłącznie w tym, co przeglądarka musi pobrać i wykonać po otrzymaniu HTML-a.
Dane z raportów CrUX
Z publicznie dostępnych danych CrUX wynika, że sklepy na Hyva znacznie częściej przechodzą wszystkie trzy progi Core Web Vitals jednocześnie. W przypadku Luma odsetek sklepów z pełnym “good” na mobile oscyluje w okolicach 10-15%. Na Hyva to 60-80%.
Wpływ na SEO i konwersję
Core Web Vitals jako czynnik rankingowy
Od 2021 roku Core Web Vitals są oficjalnym sygnałem rankingowym Google. W praktyce ich wpływ na pozycje jest niewielki w porównaniu do jakości treści, linków czy trafności zapytania. Google samo mówi o CWV jako o “tie-breakerze”, który przy równych warunkach może przechylić szalę na korzyść szybszej strony.
To nie znaczy, że można je ignorować. Przy dwóch sklepach rywalizujących o tę samą frazę z dużym wolumenem, ten z lepszymi CWV będzie miał przewagę. W przypadku sklepów z dużym katalogiem, które konkurują na tysiącach fraz long tail, efekt się kumuluje.
Jeśli interesuje Cię kompleksowe podejście do SEO dla Magento, zapraszam na stronę naszej usługi: SEO dla Magento.
Konwersja i UX - tu jest prawdziwa wartość
Ważniejszy od samego rankingu jest wpływ szybkości na konwersję. Badania Google i Deloitte konsekwentnie pokazują korelację między czasem ładowania a współczynnikiem konwersji:
- redukcja czasu ładowania o 0.1 s podnosi konwersję o 8-10% (dane Deloitte dla dużych retailerów)
- strony ładujące się powyżej 3 sekund tracą ponad 50% użytkowników mobilnych (dane Google)
- współczynnik odrzuceń rośnie wykładniczo po przekroczeniu 3 sekund czasu ładowania
Zróbmy to na liczbach. Twój sklep na Luma ma LCP 6 sekund. Migracja na Hyva obniża go do 2 sekund. Przy przychodach 5 mln zł rocznie i konwersji 1,5%, wzrost konwersji o 10-15% to dodatkowe 500-750 tys. zł rocznie. Migracja kosztuje 50-100 tys. zł. Zwrot w 2-3 miesiące. Nie ma tu co się zastanawiać, jest co liczyć.
Koszty migracji na Hyva
Dobra, skoro liczby wyglądają obiecująco, to teraz rzeczywistość. Migracja na Hyva to nie jest zmiana motywu jednym kliknięciem. To projekt deweloperski, który wymaga przepisania warstwy frontendowej. Mówię to wprost, żeby uniknąć nierealistycznych oczekiwań.
Licencja Hyva
Hyva wymaga zakupu licencji. Na początek 2026 roku koszty kształtują się następująco:
- licencja na jeden sklep (jedną domenę): ok. 1000 EUR
- licencja deweloperska (nieograniczona liczba sklepów): ok. 4500 EUR
- licencja obejmuje rok aktualizacji, po tym okresie odnowienie kosztuje ok. 30% ceny początkowej
Koszty wdrożenia
Tu rozstrzał jest duży i zależy od stopnia customizacji Twojego sklepu:
- sklep z minimalnymi modyfikacjami (standardowe moduły, podstawowe zmiany w wyglądzie): 2-4 tygodnie pracy dewelopera, koszt rzędu 15 000-30 000 PLN
- sklep ze średnim poziomem customizacji (kilkanaście rozszerzeń, niestandardowy checkout, integracje z zewnętrznymi systemami): 2-4 miesiące, koszt rzędu 40 000-100 000 PLN
- mocno zmodyfikowany sklep (custom modules z własnym frontendem, złożone kalkulatory cen, konfiguratory produktów, multi-store z różnymi layoutami): 4-6 miesięcy, koszt rzędu 100 000-250 000 PLN
Dlaczego koszty są tak wysokie?
Każdy moduł Magento, który renderuje coś na froncie, musi mieć swoją wersję kompatybilną z Hyva. Popularne rozszerzenia (Amasty, Mageworx, Mageplaza) często mają już gotowe paczki kompatybilności, ale moduły custom trzeba przepisać ręcznie. Checkout i koszyk, które w Luma opierają się na KnockoutJS, wymagają kompletnej reimplementacji w Alpine.js.
Stawki deweloperów
Deweloperzy Magento ze znajomością Hyva to wciąż stosunkowo wąska specjalizacja. Stawki na polskim rynku to 150-300 PLN/h netto za doświadczonego programistę. W agencjach zachodnioeuropejskich stawki sięgają 100-150 EUR/h.
Kiedy migracja na Hyva ma sens
Nie każdy sklep na Magento potrzebuje Hyva. Oto sytuacje, w których migracja jest uzasadniona:
- duży katalog produktów z istotnym ruchem organicznym, gdzie poprawa CWV przełoży się na lepsze pozycje i wyższą konwersję. Jeśli zarządzasz sklepem z setkami tysięcy produktów, zapoznaj się z naszym artykułem o SEO dla dużych katalogów Magento
- sklep, w którym mobile stanowi ponad 60% ruchu, bo to właśnie na urządzeniach mobilnych różnica między Luma a Hyva jest najbardziej widoczna
- długoterminowe zaangażowanie w ekosystem Magento, co oznacza, że inwestycja w nowy frontend zwróci się w ciągu 2-3 lat
- konkurencja w branży, gdzie UX i szybkość działania bezpośrednio wpływają na decyzje zakupowe (elektronika, moda, kosmetyki)
- planowana przebudowa frontendu, bo jeśli i tak zamierzasz odświeżyć wygląd sklepu, migracja na Hyva pozwala połączyć dwie inwestycje w jedną
Kiedy migracja NIE ma sensu
Są też sytuacje, w których wydatek na Hyva jest trudny do uzasadnienia:
- planowana migracja z Magento na inną platformę w perspektywie 12-18 miesięcy. Jeśli rozważasz przejście na Shopify Plus, WooCommerce lub dedykowane rozwiązanie, nie ma sensu inwestować w nowy frontend dla platformy, którą zamierzasz porzucić
- minimalny poziom customizacji, gdzie prostsze optymalizacje Luma (Varnish, Redis, optymalizacja obrazów, krytyczne CSS) mogą wystarczyć do osiągnięcia akceptowalnych wyników. Nie będzie to 90 punktów PageSpeed, ale 50-60 może być wystarczające
- ograniczony budżet i konieczność wyboru między Hyva a innymi inwestycjami w SEO (treści, link building, optymalizacja techniczna). Czasem lepsza treść da większy zwrot niż szybszy frontend
- sklep B2B z niskim ruchem mobilnym, gdzie większość klientów korzysta z desktopów w biurze. Na desktopie różnica między Luma a Hyva jest mniej dramatyczna
SEO checklist przy migracji na Hyva
Migracja frontendu to z perspektywy Google zmiana strony. Jeśli nie przygotujesz się odpowiednio, możesz stracić pozycje, nawet jeśli nowy frontend jest szybszy. Oto kluczowe elementy, o które trzeba zadbać.
Przed migracją
- wykonaj pełny crawl obecnego sklepu (Screaming Frog, Sitebulb) i zapisz listę wszystkich zaindeksowanych URL-i
- zrób zrzut aktualnych pozycji dla kluczowych fraz
- sprawdź, czy wszystkie dane strukturalne (schema.org) są poprawnie zaimplementowane w nowym motywie
- zweryfikuj, że sitemap XML generuje się poprawnie z Hyva
Podczas migracji
- zachowaj identyczną strukturę URL. Hyva zmienia frontend, nie routing, więc teoretycznie URL-e nie powinny się zmienić. W praktyce trzeba to zweryfikować
- upewnij się, że tagi kanoniczne, hreflang (przy multi-store), meta title i meta description są identyczne
- sprawdź, czy lazy loading obrazów nie blokuje LCP image (element LCP powinien ładować się eager, nie lazy)
- przetestuj renderowanie stron w Google Search Console (Inspekcja URL) lub narzędziu Mobile-Friendly Test
Po migracji
- monitoruj Google Search Console przez 4-6 tygodni: indeksacja, błędy crawlowania, spadki wyświetleń
- porównaj dane CrUX z okresu przed i po migracji (potrzeba ok. 28 dni na zebranie nowych danych)
- sprawdź w GA4, czy współczynnik konwersji rzeczywiście się poprawił
- ustaw alerty na anomalie w ruchu organicznym, żeby szybko zareagować na ewentualne problemy
Często zadawane pytania
Czy Hyva działa ze wszystkimi rozszerzeniami Magento?
Nie. Każde rozszerzenie, które renderuje elementy na froncie, wymaga wersji kompatybilnej z Hyva. Popularne rozszerzenia od Amasty, Mageworx czy Mageplaza w większości mają już takie wersje, ale moduły niestandardowe trzeba przepisać. Przed podjęciem decyzji o migracji warto przygotować listę wszystkich zainstalowanych rozszerzeń i sprawdzić ich kompatybilność na stronie Hyva Compatibility Tracker.
Czy migracja na Hyva wymaga zmiany hostingu?
Nie. Hyva zmienia wyłącznie warstwę frontendową. Backend Magento, baza danych, konfiguracja serwera, Varnish, Redis, Elasticsearch, to wszystko pozostaje bez zmian. Paradoksalnie, lżejszy frontend może nawet zmniejszyć obciążenie serwera, bo generuje mniej requestów.
Ile czasu zajmuje migracja na Hyva?
Od 2-4 tygodni dla prostego sklepu z minimalnymi modyfikacjami, do 4-6 miesięcy dla sklepu z rozbudowaną customizacją. Kluczowym czynnikiem jest liczba modułów z własnym frontendem, złożoność checkoutu i liczba store views. Warto zaplanować migrację na okres niższego ruchu (np. styczeń-luty w branży modowej), żeby zminimalizować ryzyko.
Czy Hyva wpłynie na moje pozycje w Google?
W pozytywnym kierunku, pod warunkiem prawidłowo przeprowadzonej migracji. Poprawa Core Web Vitals to sygnał rankingowy. Ale jeśli migracja wprowadzi błędy (zmienione URL-e, brakujące dane strukturalne, problemy z indeksacją), efekt może być odwrotny. Dlatego checklist z poprzedniej sekcji jest tak ważny.
Czy warto czekać na PWA Studio lub headless zamiast Hyva?
PWA Studio (oficjalne rozwiązanie Adobe do headless commerce) ma znacznie wyższy próg wejścia: wymaga osobnego frontendu w React, GraphQL API, oddzielnego hostingu dla frontendu i zupełnie innego podejścia do developmentu. Koszty wdrożenia PWA Studio bywają wielokrotnie wyższe niż Hyva, a ekosystem modułów mniejszy. Hyva to pragmatyczny kompromis: radykalna poprawa wydajności przy zachowaniu tradycyjnej architektury Magento, z którą deweloperzy są zaznajomieni. Dla większości sklepów to lepszy wybór niż pełny headless.
Podsumowanie
Hyva Theme rozwiązuje fundamentalny problem wydajnościowy Magento 2. Redukcja JavaScriptu o ponad 90% przekłada się na radykalną poprawę Core Web Vitals, co z kolei wpływa na pozycje w Google i, co ważniejsze, na konwersję.
Migracja nie jest jednak decyzją, którą podejmuje się pochopnie. To projekt deweloperski o budżecie od kilkunastu do kilkuset tysięcy złotych, wymagający starannego planowania i kontroli SEO na każdym etapie.
Jeśli Twój sklep na Magento generuje istotny ruch organiczny, ma problemy z Core Web Vitals na mobile i planujesz pozostać na tej platformie przez najbliższe lata, Hyva to inwestycja, która się zwróci. Jeśli rozważasz migrację lub szukasz wsparcia w optymalizacji SEO dla Magento, zapraszam do kontaktu.
Rozważasz migrację frontendu Magento?
Przed decyzją sprawdzimy Core Web Vitals, moduły, ryzyka SEO i realny zakres prac dla Twojego sklepu.