Hyvä läuft jetzt nativ auf Magento 2.4.9 und auf Mage-OS. Wir haben beides getestet. Was das für Ihren Shop bedeutet →
Kurz gesagt
Auf demselben Server mit demselben Katalog waren saubere Hyvä-Seiten etwa 4-mal leichter als Luma, erzeugten 13- bis 18-mal weniger Requests und lieferten 18- bis 20-mal weniger JavaScript aus. Der mobile LCP war rund 35 % schneller. Die Lighthouse-Scores lagen näher beieinander, als das Gewicht vermuten lässt – denn der eigentliche Unterschied liegt in der Last, nicht im Laborwert.
Die meisten Vergleiche zwischen Hyvä und Luma stellen einen frischen Hyvä-Shop einem alten, stark angepassten Luma-Shop gegenüber. Damit sieht Hyvä großartig aus, aber man erfährt nicht, was das Frontend selbst verändert.


Wir wollten einen fairen Test. Deshalb haben wir beide Frontends auf denselben Server mit demselben Katalog gestellt und dieselben Seiten gemessen.
So haben wir getestet
Der Aufbau war bewusst unspektakulär, damit das Theme die einzige Variable blieb.
- Eine saubere Magento-2.4.9-Installation mit Hyvä 1.5.2 im Vergleich zu Magentos eigenem Luma-Theme.
- Derselbe Server, derselbe Katalog und dieselbe Konfiguration für beide.
- Drei Seitentypen: Startseite, Kategorie und Produkt.
- Lighthouse 13, mit dem Median aus 3 mobilen Durchläufen plus 1 Desktop-Durchlauf pro Seite.
Wir haben Lighthouse per Kommandozeile in Headless Chrome mit einem normalen Browser-User-Agent ausgeführt. Unser nginx blockiert Bot-User-Agents, und ein blockierter Test liefert eine 403-Seite, die einen falschen, bedeutungslosen Score erzeugt.
Außerdem haben wir den Cache vor jeder Messreihe geleert und aufgewärmt und die echten URLs hinter dem CDN getestet. Die vollständige Methodik finden Sie in unserem Beitrag wie wir die Hyvä-Geschwindigkeit mit Lighthouse testen.
Die Ergebnisse
| Metrik | Hyvä | Luma |
|---|---|---|
| Seitengewicht (Start / Kategorie / Produkt) | 226 / 195 / 206 KB | 962 / 756 / 805 KB |
| Requests pro Seite | 15–19 | 251–275 |
| JavaScript pro Seite | ~26 KB | 463–524 KB |
| Mobiler LCP | 1.5–1.6 s | 2.3–2.5 s |
| Mobiler Lighthouse-Score | 93–100 | 88–99 |
| Desktop-Lighthouse-Score | 99–100 | 97–100 |
Kurz gesagt: Hyvä-Seiten waren etwa viermal leichter. Sie erzeugten rund 13- bis 18-mal weniger Requests. Sie lieferten rund 18- bis 20-mal weniger JavaScript aus. Der mobile LCP war etwa 35 % schneller.
Woher das Gewicht kommt
Der Unterschied liegt vor allem beim JavaScript und bei der Anzahl der Dateien.
Eine Luma-Seite lädt RequireJS, das wiederum jQuery, KnockoutJS, jQuery-UI-Widgets und eine lange Liste kleiner Module nachlädt. Jedes Modul ist ein eigener Request, sofern man sie nicht bündelt – und das Bundling in Luma richtig hinzubekommen, ist bekanntermaßen schwierig.
Eine Hyvä-Seite lädt Alpine.js und die geringe Menge seitenspezifischer Skripte, die direkt in den Templates stehen. Die Styles stammen aus einer einzigen Tailwind-CSS-Datei, die nur die Klassen enthält, die das Theme tatsächlich verwendet.
Deshalb sinkt die Zahl der Requests von über 250 auf unter 20. Und deshalb sinkt das JavaScript von etwa einem halben Megabyte auf rund 26 KB.
Beide Stacks im direkten Vergleich erklären wir in wie Alpine.js und Tailwind RequireJS und Knockout ersetzen.
Ehrlich gesagt: Auch Luma hat gut abgeschnitten
Sehen Sie sich die Lighthouse-Zeile noch einmal an. Ein sauberes Luma-Theme erreichte mobil zwischen 88 und 99.
Das ist kein Fehler. Ein sauberer Luma-Shop im Production-Modus, auf einem schnellen Server, hinter Cloudflare und ohne weitere Installationen kann in einem Labortest gut abschneiden.
Echte Luma-Shops sehen selten so aus. Sie nutzen Extensions, Tracking-Skripte, Chat- und Bewertungs-Widgets, und jedes davon packt weiteres JavaScript auf eine ohnehin schwere Basis.
Die nützliche Erkenntnis ist also nicht, dass Hyvä einen höheren Score erzielt. Die nützliche Erkenntnis ist, dass Hyvä von einer viel leichteren Basis aus startet – und damit Raum für das lässt, was ein echter Shop braucht.
Warum Laborwerte den Unterschied unterschätzen
Lighthouse simuliert ein Mittelklasse-Smartphone mit gedrosselter Verbindung. Es ist ein gutes, reproduzierbares Werkzeug, aber eben eine Simulation auf einem schnellen Rechner.
Auf einem echten Einsteiger-Smartphone muss ein halbes Megabyte JavaScript von einem langsamen Prozessor heruntergeladen, geparst und ausgeführt werden. Diese Arbeit blockiert den Main Thread und verzögert jeden Tipp.
Genau hier leidet Interaction to Next Paint, kurz INP. Wer auf “In den Warenkorb” tippt und warten muss, spürt den Unterschied – auch wenn der Laborwert gut aussah.
Mit rund 26 KB JavaScript hat eine Hyvä-Seite schlicht viel weniger zu verarbeiten. Unsere Core-Web-Vitals-Checkliste für Magento 2 behandelt die weiteren Stellschrauben für LCP und INP.
Was das für einen echten Shop bedeutet
Ein Benchmark auf einer sauberen Installation ist ein Ausgangspunkt, kein Versprechen. Ihre eigenen Zahlen hängen von Ihren Extensions, Bildern, Skripten und Ihrem Server ab.
Das haben wir in echten Projekten gesehen:
- In einem Kundenshop – einem deutschen Händler, der in 9 Länder verkauft – stieg der mobile Lighthouse-Score der Produktseite nach dem Umstieg auf Hyvä von 72 auf 94. Die Kategorieseite stieg von 88 auf 95. Das sind unsere Messungen auf dem Staging-Build.
- In unserem eigenen Hyvä-Demo-Shop mit echten Produktbildern, zwei Store Views und einem internationalen Checkout haben wir mobil 96 auf der Startseite, 90 auf der Kategorie- und 92 auf der Produktseite gemessen. Auf dem Desktop waren es 100, 100 und 98.
Die Werte des Demo-Shops liegen unter denen des sauberen Benchmarks, weil er echte Inhalte trägt. Das ist normal und genau der Grund, warum wir jeden Shop einzeln messen.
So nutzen Sie diese Zahlen
Wenn Sie einen Umstieg abwägen, vergleichen Sie nicht Ihren Live-Shop auf Luma mit der Hyvä-Demo eines Anbieters. Vergleichen Sie Gleiches mit Gleichem.
- Messen Sie Ihre aktuelle Start-, Kategorie- und Produktseite mit einer einheitlichen Methode.
- Listen Sie Ihre Extensions und Drittanbieter-Skripte auf, denn sie entscheiden, wie viel vom Gewinn Ihnen bleibt.
- Prüfen Sie Ihren Server und Ihr Cache-Setup, denn Hyvä kann kein langsames Backend reparieren.
- Erst dann schätzen Sie ab, was Hyvä für Ihren Shop verändern würde.
Wenn wir einen Hyvä-Shop bauen, sichern wir zum Launch einen mobilen Lighthouse-Performance-Score von mindestens 89 für Start-, Kategorie- und Produktseiten zu. Das gilt auf einem für Hyvä optimierten Server und mit den im Projektplan vereinbarten Bildern und Skripten.
FAQ
Warum haben Sie ein sauberes Luma statt eines echten Shops getestet?
Eine saubere Installation isoliert den Effekt des Frontends selbst. Echte Shops packen Extensions und Skripte obendrauf, was den Abstand meist noch vergrößert.
Erzielt Hyvä in Lighthouse immer höhere Scores?
Nicht immer mit großem Abstand. Der größere und verlässlichere Unterschied liegt bei Seitengewicht, Anzahl der Requests und JavaScript – und das wirkt sich auf echte Kunden stärker aus, als der Laborwert zeigt.
Ist ein um 35 % schnellerer LCP spürbar?
Ja, vor allem mobil. In unserem Test sank der mobile LCP von etwa 2,3 bis 2,5 Sekunden bei Luma auf etwa 1,5 bis 1,6 Sekunden bei Hyvä.
Sie möchten denselben Vergleich für Ihren eigenen Shop? Sehen Sie sich unseren Luma-vs.-Hyvä-Vergleich an und erfahren Sie, wie wir einen Hyvä-Umstieg planen, auf der Seite Hyvä-Theme-Entwicklung .


