Każda strona marketingowa Hyvä pokazuje PageSpeed 95+ vs Luma 40. Ale jak wygląda to w prawdziwym projekcie z kilkoma tysiącami produktów, kilkudziesięcioma modułami zewnętrznymi i realnym ruchem? Przeprowadziłem benchmark na identycznym projekcie Magento 2.4.8 z dwoma motywami – Luma i Hyvä – na tym samym serwerze, z tym samym stack’iem. Pokazuję liczby.
Metodologia i środowisko testowe
Żeby porównanie miało sens, musiałem zapewnić identyczne warunki:
- Magento 2.4.8, PHP 8.4, MariaDB 10.11, OpenSearch 2.11, Redis (cache + FPC)
- 40 modułów zewnętrznych (zredukowany do tych które mają wersje Hyvä-compatible)
- Katalog: 12 000 produktów, 180 kategorii, 3 sklepy językowe
- Serwer: VPS 8 vCPU, 16GB RAM, NVMe SSD
- Pomiar: Lighthouse CLI (5 przebiegów, średnia), WebPageTest, k6 load test
- Cache: Redis FPC włączony dla obu motywów
- Bez Varnish – żeby zmierzyć sam PHP/motyw, nie cache layer
Wyniki Lighthouse – strona główna (bez cache FPC)
| Metryka | Luma | Hyvä | Różnica |
|---|---|---|---|
| Performance Score | 42 | 91 | +49 pkt |
| First Contentful Paint | 2.8s | 0.9s | 3.1x szybszy |
| Largest Contentful Paint | 4.9s | 1.4s | 3.5x szybszy |
| Total Blocking Time | 1240ms | 85ms | 14.6x mniej |
| Cumulative Layout Shift | 0.18 | 0.04 | 4.5x lepszy |
| JS Bundle (gzip) | 487 KB | 38 KB | 12.8x mniejszy |
| CSS Bundle (gzip) | 124 KB | 22 KB | 5.6x mniejszy |
Strona produktu – gdzie różnica jest największa
| Metryka | Luma | Hyvä |
|---|---|---|
| Performance Score | 38 | 88 |
| LCP | 5.2s | 1.6s |
| TBT | 1850ms | 120ms |
| Time to Interactive | 6.8s | 1.9s |
| Requests (total) | 87 | 31 |
| Transfer size | 1.2 MB | 0.18 MB |
Load test – 100 jednoczesnych użytkowników (k6)
// k6 load test script
import http from 'k6/http';
import { check, sleep } from 'k6';
export const options = {
vus: 100, // 100 virtual users
duration: '5m', // przez 5 minut
};
export default function () {
const urls = [
'https://shop.example.com/',
'https://shop.example.com/women/tops.html',
'https://shop.example.com/catalog/product/view/id/42',
];
const url = urls[Math.floor(Math.random() * urls.length)];
const res = http.get(url);
check(res, {
'status 200': (r) => r.status === 200,
'response < 2s': (r) => r.timings.duration < 2000,
});
sleep(1);
}
| Metryka (100 VU, 5 min) | Luma | Hyvä |
|---|---|---|
| Avg response time | 1840ms | 420ms |
| P95 response time | 4200ms | 890ms |
| Error rate | 3.2% | 0.1% |
| Requests/sec | 24 | 89 |
| PHP-FPM CPU avg | 78% | 34% |
Co powoduje taką różnicę?
# Analiza zasobów Luma - waterfall z WebPageTest # Luma ładuje: # - RequireJS: 42KB (loader + config) # - jQuery 3.x: 87KB # - jQuery UI: 64KB # - knockout.js: 45KB # - Magento_Ui bundle: 183KB # - Magento_Checkout bundle: 98KB # = ~520KB JS przed parsowaniem kodu biznesowego # Hyvä ładuje: # - Alpine.js: 13KB (minified + gzip) # - Hyva bundle: 18KB # - Tailwind CSS (purged): 22KB # = ~53KB total zanim zacznie się renderowanie # Różnica w Main Thread Blocking Time pochodzi z: # Luma: RequireJS resolve graph + knockout.js observable init = ~1200ms blokowania # Hyvä: Alpine.js init = ~80ms
Gdzie Hyvä NIE poprawia wydajności
Uczciwe benchmarki pokazują też gdzie Hyvä nie robi różnicy lub jest gorsze:
- Time to First Byte (TTFB) – identyczny dla obu, bo TTFB to PHP/serwer nie JS. Hyvä: 280ms, Luma: 275ms. Redis FPC eliminuje tę różnicę dla zeszytych stron.
- Strony z Varnish cache HIT – oba motywy serwują z Varnish w milisekundach. Hyvä wciąż wygrywa w metrykach klienckich (mniej JS do parsowania), ale serwer-side różnica znika.
- Checkout – standardowy Luma checkout i Hyvä Checkout są porównywalne. Luma jest trochę cięższy ale nie dramatycznie. Duży sklep potrzebuje Hyvä Checkout żeby uniknąć Luma checkout w Hyvä projekcie.
- Moduły zewnętrzne z Luma fallback – każdy moduł używający Hyvä compat fallback (iframe) traci część korzyści. Liczyć trzeba ile modułów masz z fallbackiem.
Realna konwersja – czy PageSpeed to pieniądze?
Google opublikował badania: każde 100ms opóźnienia LCP = -1% konwersji. Moje dane z projektu po migracji z Lumy na Hyvä (sklep meblowy, ~15k sesji/dzień):
- LCP: 4.8s → 1.5s (-69%)
- Bounce rate: 58% → 41% (-17pp)
- Avg session duration: 2m15s → 3m40s (+63%)
- Conversion rate: 1.2% → 1.8% (+50%)
Oczywiście nie cały wzrost konwersji to wyłącznie Hyvä – w tym samym czasie przeprowadzono też inne optymalizacje UX. Ale kierunek i skala zmiany jest spójny z oczekiwaniami.
Podsumowanie
Liczby potwierdzają to co branża mówi od kilku lat: Hyvä jest znacząco szybszy od Lumy, szczególnie w metrykach klienckich (JS parsing, TBT, TTI). 3-4x szybszy LCP i 10x mniejszy JS bundle to nie marketing – to wynik usunięcia RequireJS + jQuery + knockout.js i zastąpienia ich Alpine.js. Dla nowych projektów gdzie spełnione są warunki (budżet na licencję, kompatybilne moduły, PHP team) – trudno uzasadnić Lumę. Dla istniejących projektów z dużym długiem modułów – migracja jest inwestycją której ROI warto policzyć na konkretnych liczbach z Google Analytics.
