---
title: "Hyvä kontra Luma, na liczbach"
description: "Co naprawdę spowalnia Lumę, co zmienia Hyvä i jak zmierzyć różnicę na własnym katalogu, zamiast polegać na materiałach sprzedażowych."
author: "Luboš Zápotočný"
published: "2026-05-21"
language: "pl"
canonical: "https://zapolu.com/pl/blog/hyva-vs-luma/"
---

# 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ä](https://hyva.io) 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](https://alpinejs.dev) 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:

1. **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.
2. **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.
3. **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.
4. **Ś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](/pl/blog/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](/pl/services/performance-audit/). Tak też zaczyna
się większość naszej [pracy przy Magento](/pl/services/magento/).