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. Diese Einschätzung sollten Sie jedoch weder von uns noch von einem Anbieter mit Verkaufsinteresse ungeprüft übernehmen. Dieser Beitrag erklärt, was die beiden Frontends strukturell unterscheidet und wie Sie den Abstand am eigenen Shop messen, bevor Sie ein Budget dafür freigeben.

Warum Luma per Konstruktion langsam ist

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

• RequireJS lädt JavaScript als Abhängigkeits-Wasserfall. Der Browser erfährt erst nach dem Ausführen des bereits Geladenen, was er als Nächstes holen muss. Auf einer kalten Mobilfunkverbindung 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-Component-Schicht werden auf jeder Seite ausgeliefert, 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.

Nichts davon taucht im Profiler als einzelne langsame Zeile auf. Es zeigt sich als Megabytes an JavaScript und ein Main Thread, der auf Mittelklasse-Telefonen sekundenlang beschäftigt ist. Genau diese Geräte nutzen Ihre Kunden.

Was Hyvä tatsächlich ändert

Hyvä ist ein vollwertiges Ersatz-Theme. Es ersetzt 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 klar unter hundert Kilobyte, was Sie im Netzwerk-Tab jedes Browsers am Demo-Shop selbst nachprüfen können.

Dabei gilt eine wesentliche Einschränkung: 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 Ihr maßgeschneidertes Modul von 2019 ist es leer. Im Extension-Audit stecken deshalb die echten Kosten eines Hyvä-Projekts; die Theme-Lizenz ist der kleinere Posten.

Der Checkout ist eine eigene Entscheidung: Hyvä behält von Haus aus den Luma-Checkout, sofern Sie nicht Hyvä Checkout oder eine headless Variante einführen, und gerade dort 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. Holen 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. Ein ungedrosselter Lab-Lauf auf einem schnellen Entwicklerrechner kann weit besser aussehen als das, was echte Besucher auf Mittelklasse-Telefonen 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. Das meiste nach der TTFB ist das, was ein Frontend-Wechsel adressieren kann; ein langsames Backend oder Netzwerk braucht seine eigene Lösung.
3. Setzen Sie den Vergleich ehrlich auf. 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. Conversion nach Geräteklasse, vorher und nachher. Der Score ist am Ende nur ein Hilfswert.

Wann die Antwort nicht Hyvä ist

Hyvä ist unsere Standardempfehlung für Luma-Shops mit Performance-Problem, aber keine automatische Antwort. Ein Shop mit 4 Sekunden TTFB hat ein Backend-Problem. Ein Shop, der bereits auf PWA Studio läuft, steht vor einer anderen Fragestellung. 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.