Hyvä vs. Luma, nachgemessen

Jede Diskussion über Magento-Performance landet früher oder später bei derselben Frage: Ist das Frontend das Problem, und ist Hyvä die Antwort? Beide Male gilt: meistens ja. Prüfen Sie das dennoch am eigenen Shop nach, statt es uns oder einem Anbieter, der Ihnen einen Rebuild verkaufen will, ungeprüft abzunehmen. Dieser Beitrag erklärt, was die beiden Frontends strukturell unterscheidet und wie Sie den Abstand messen, bevor Sie ein Budget dafür freigeben.

Warum Luma konstruktionsbedingt langsam ist

Luma, das mitgelieferte Magento-Frontend, ist langsam wegen Entscheidungen, die um 2015 herum in der Plattform getroffen wurden:

• RequireJS lädt JavaScript in einem Wasserfall aus Abhängigkeiten. Der Browser erfährt erst nach dem Ausführen des bereits Geladenen, was er als Nächstes holen muss. Auf einer Mobilfunkverbindung mit hoher Latenz heißt das: Roundtrip um Roundtrip, bevor die Seite interaktiv wird.
• Mehrere schwere JS-Schichten werden gleichzeitig ausgeliefert. jQuery, KnockoutJS und Magentos Knockout-basierte UI-Komponenten-Schicht landen auf jeder Seite, ob die Seite sie nutzt oder nicht.
• Layout-XML rendert mehr als nötig. Blöcke, die niemand sieht, werden trotzdem gebaut, und Drittanbieter-Extensions hängen ihre Skripte global ein statt dort, wo sie gebraucht werden.

Im Profiler taucht davon keine einzelne langsame Zeile auf, wohl aber Megabytes an JavaScript und ein Main Thread, der auf den Mittelklasse-Smartphones Ihrer Kunden sekundenlang beschäftigt ist.

Was Hyvä tatsächlich ändert

Hyvä ist ein Ersatz-Theme. Es entfernt den Luma-Frontend-Stack vollständig: kein RequireJS, kein jQuery, kein Knockout. Die Templates sind serverseitig gerendertes PHP mit Alpine.js für die Interaktivität und Tailwind für die Styles. In unseren eigenen Messungen fällt die JavaScript-Payload typischerweise von deutlich über einem Megabyte auf weit unter hundert Kilobyte, was Sie im Netzwerk-Tab jedes Browsers am Demo-Shop selbst nachprüfen können.

Der Trade-off: Jede Extension, die das Frontend berührt, braucht ein Hyvä-kompatibles Modul oder einen Rewrite. Für populäre Extensions ist das Kompatibilitäts-Ökosystem ausgereift, für ältere maßgeschneiderte Module fehlt es oft. Der größte Teil der Kosten eines Hyvä-Projekts steckt im Extension-Audit.

Der Checkout ist eine eigene Entscheidung. Eine Standardinstallation von Hyvä behält den Luma-Checkout, und zwar über den Luma Theme Fallback; Hyvä Checkout ist ein eigenes Produkt (Hyvä-Dokumentation, geprüft am 22. Juli 2026). Gerade am Checkout entscheidet sich oft die Conversion.

Wie Sie selbst messen

Vergleichen Sie nicht Ihren Produktions-Shop mit einer Hyvä-Demo; das vermengt Theme, Katalog, Hosting und Drittanbieter-Skripte. Ein fairer Vergleich sieht so aus:

1. Ermitteln Sie die Baseline aus Felddaten, nicht nur aus Lighthouse. CrUX (über PageSpeed Insights) zeigt, was echte Besucher über 28 Tage erlebt haben: LCP, INP, CLS. Eine ungedrosselte Labormessung auf einem schnellen Entwicklerrechner kann weit besser aussehen als das, was echte Besucher auf Mittelklasse-Smartphones bekommen.
2. Trennen Sie Frontend und Backend. Die TTFB wird von Backend und Netzwerk bestimmt (Server, DNS, TLS); liegt die TTFB bei 1,5 s, löst ein Theme-Wechsel das Problem nicht. Was nach der TTFB passiert, ist zum größten Teil das, woran ein Frontend-Wechsel etwas ändern kann; ein langsames Backend oder Netzwerk braucht seine eigene Lösung.
3. Setzen Sie den Vergleich ehrlich an. Gleicher Server, gleicher Katalog, gleiche Extensions aktiv, Drittanbieter-Tags entweder in beiden Fällen an oder in beiden aus. Lassen Sie Lighthouse mehrfach laufen und vergleichen Sie Mediane, denn Einzelläufe schwanken stark.
4. Verfolgen Sie die Geschäftskennzahl parallel. Erfassen Sie die Conversion nach Geräteklasse vorher und nachher und bewerten Sie das Projekt daran, nicht am Lighthouse-Score.

Wann die Antwort nicht Hyvä ist

Hyvä ist unsere Standardempfehlung für Luma-Shops mit Performance-Problem, aber nicht für jeden Shop. Ein Shop mit 4 Sekunden TTFB hat ein Backend-Problem. Ein Shop, der bereits auf PWA Studio läuft, steht vor anderen Abwägungen. Und ein Shop kurz vor dem Replatforming sollte in keines von beiden investieren. Das ist zuerst eine Frage von Replatforming oder Reparatur.

Wenn Sie die Messung nicht selbst durchführen möchten, übernimmt das unser Performance-Audit, mit Frontend/Backend-Split, Extension-Audit und priorisierter Maßnahmenliste. So beginnt auch der Großteil unserer Magento-Arbeit.