Hyva Theme a Core Web Vitals: czy warto migrować frontend Magento?

Jarosław Bazylewicz
11 min czytania

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.

Gotowy na strategiczne partnerstwo w marketingu cyfrowym?

Porozmawiajmy o Twoich wyzwaniach i celach. Opracujemy dopasowaną strategię i plan działania, które przyniosą mierzalne rezultaty dla Twojego e-commerce lub instytucji.