Hyvä, PWA oder auf Luma bleiben? Ein Entscheidungsrahmen für das Magento-Frontend mit echten Kosten

Wenn Sie einen Magento-2-Shop betreiben, hat Ihnen jemand gesagt, dass Ihr Frontend das Problem ist. Häufig stimmt das. Luma — das Standard-Theme von Magento — liefert RequireJS und Knockout.js an jeden Besucher aus, und auf einem Android-Mittelklassegerät kostet allein dieser Stack zwei Sekunden, bevor das erste Produktbild erscheint.

Aber das Frontend ist langsam ist ein Symptom, keine Handlungsanweisung. Die drei Antworten, die im Raum stehen — Migration zu Hyvä, eine PWA-Storefront bauen oder das vorhandene Luma-Theme optimieren — unterscheiden sich in den Kosten um rund eine Größenordnung und im Risiko etwa genauso. Falsch zu wählen gehört zu den teureren Fehlern, die einem Magento-Händler offenstehen, und wer Ihnen die Antwort verkauft, verkauft in der Regel genau eine der drei.

Wir bauen alle drei. Das hier ist der Rahmen, den wir intern nutzen, bevor wir irgendetwas anbieten — einschließlich der Fälle, in denen wir einem Kunden raten, gar nichts auszugeben.

Die drei Optionen, ehrlich beschrieben

Option 1: Das vorhandene Luma-Theme optimieren

Die Option, die niemand anbietet, weil sie die kleinste Rechnung ergibt. Luma ist vor allem deshalb langsam, weil so viel daran angebaut wurde: Extensions von Drittanbietern, die eigenes JavaScript einschleusen, ungebündelte RequireJS-Module, unoptimierte Medien, ein Full-Page-Cache, der öfter danebengreift als allen bewusst ist, und eine Varnish-Konfiguration, die vor drei Jahren richtig war.

Ein disziplinierter Optimierungsdurchgang — Extension-Audit, Critical CSS, verzögertes JavaScript, Bild-Pipeline, Cache-Warming, Datenbank- und Redis-Tuning — bringt einen Luma-Shop routinemäßig von einer nicht bestandenen Core-Web-Vitals-Bewertung zu einer bestandenen. Nicht zu einem Lighthouse-Score von 100. Zu einer bestandenen Bewertung — und die ist es, die Rankings und Conversion tatsächlich beeinflusst.

• Typische Kosten: £8.000–£25.000, je nach Umfang der Extension-Altlasten
• Typische Dauer: 4–8 Wochen, schrittweise am laufenden Shop ausgeliefert
• Risiko: gering — jede Änderung ist reversibel, und an der Struktur der Storefront ändert sich nichts
• Obergrenze: real. Luma kann nur bis zu einem bestimmten Punkt schnell werden, und schwere Kategorieseiten bleiben schwer

Das ist die Arbeit, die wir unter PageSpeed-Optimierung leisten, und damit beginnen wir bei den meisten Mandaten — auch bei denen, die später in eine vollständige Frontend-Migration münden. Zu wissen, welche Ihrer Probleme Theme-Probleme sind und welche Extension-Probleme, lohnt sich, bevor Sie das Zehnfache ausgeben.

Option 2: Zu Hyvä migrieren

Hyvä ersetzt die Theme-Ebene von Luma durch Tailwind CSS und Alpine.js. Katalog, Preise, Warenkorb, Checkout und Backend bleiben genau dort, wo sie sind — das ist ein Austausch des Frontends, kein Replatforming. In der Regel entfällt der Großteil des JavaScripts, das Luma ausliefert, und es entsteht eine Storefront, die serverseitig von Haus aus schnell rendert statt erst nach Feinabstimmung.

Der Haken, und es ist der ganze Haken: jede Extension mit einer Storefront-Oberfläche muss überarbeitet werden. Hyvä hat ein Ökosystem an Kompatibilitätsmodulen, das die verbreiteten Anbieter abdeckt, aber der Long Tail — Ihr individueller Konfigurator, jene regionale Zahlungsart, das Loyalty-Widget eines Anbieters, der seit 2023 nichts mehr aktualisiert hat — ist der eigentliche Umfang Ihres Projekts. Wir haben denselben Shop von verschiedenen Agenturen zu völlig unterschiedlichen Preisen kalkuliert gesehen, nur weil die eine die Extensions gezählt hat und die andere nicht.

• Typische Kosten: £30.000–£90.000 für einen mittelgroßen Katalog, zuzüglich der Hyvä-Lizenz
• Typische Dauer: 10–20 Wochen
• Risiko: mittel — die Storefront wird neu gebaut, also muss die gesamte Customer Journey erneut getestet werden
• Obergrenze: hoch. Schneller wird eine konventionelle Magento-Storefront nicht.

Wir haben diese Umstellung oft genug gemacht, um einschätzen zu können, wo sie landet. Bei unserer Luma-zu-Hyvä-Umstellung für Shirt Tuning blieben Katalog, Preislogik und Checkout unangetastet, während das Frontend vollständig ausgetauscht wurde — genau diese Trennung macht die Migration beherrschbar. Bei PriceGuru haben wir von Anfang an auf Hyvä gebaut, was deutlich einfacher ist als die Umstellung eines etablierten Shops.

Option 3: Eine PWA-Storefront bauen

Ein Headless-Aufbau: Magento wird zur API, und die Storefront ist eine eigene JavaScript-Anwendung — PWA Studio oder zunehmend ein individuelles Next.js-Frontend, das mit GraphQL spricht. Sie gewinnen völlige Gestaltungsfreiheit, App-artige Navigation und die Möglichkeit, eine Storefront vor mehr als ein Commerce-Backend zu setzen.

Sie übernehmen damit auch eine zweite Anwendung im Betrieb, mit eigenem Hosting, eigener Deployment-Pipeline, eigenem Monitoring, eigenen Abhängigkeits-Updates und — entscheidend — einer eigenen SEO-Oberfläche, die von Hand richtig gebaut werden muss, statt vererbt zu werden. Jedes Stück nativen Storefront-Verhaltens von Magento gehört nun Ihnen. Merchandiser, die eine Seite im Backend bearbeiten konnten, können das oft nicht mehr.

• Typische Kosten: £80.000–£250.000+
• Typische Dauer: 5–9 Monate
• Risiko: hoch — das ist eine neue Anwendung, kein Theme, und sie verändert die Arbeitsweise Ihres Teams
• Obergrenze: die höchste, und die einzige Option, die später auch Backends jenseits von Magento öffnet

Der Entscheidungsrahmen

Arbeiten Sie diese Fragen der Reihe nach durch. Das erste ehrliche Ja ist meist Ihre Antwort.

1. Haben Sie tatsächlich gemessen oder reagieren Sie auf einen Lighthouse-Score?

Ein einzelner Lighthouse-Lauf auf Ihrem Laptop ist keine Messung. Sehen Sie sich die Core-Web-Vitals-Felddaten in der Search Console an — echte Besucher, echte Geräte — und schlüsseln Sie sie nach Template auf. Die meisten Magento-Shops, die wir prüfen, haben eine Startseite, die besteht, und Kategorieseiten, die deutlich durchfallen. Das ist ein punktuelles Problem, kein Problem der gesamten Storefront.

Wenn Ihre Felddaten zeigen, dass LCP bei 60 % der Aufrufe von Kategorieseiten durchfällt, Ihre Produktseiten aber in Ordnung sind, haben Sie ein Problem mit den Kategorieseiten. Das gehört diagnostiziert, bevor daraus eine Migration wird.

2. Wie viel Ihrer Langsamkeit geht auf Extensions zurück?

Deaktivieren Sie Extensions von Drittanbietern auf einem Staging-Klon, Gruppe für Gruppe, und messen Sie erneut. Regelmäßig finden wir einen einzelnen Tag Manager, ein Bewertungs-Widget oder ein Personalisierungsskript, das mehr Blocking Time verursacht als das gesamte Luma-Framework. Trifft das auf Ihren Shop zu, wird eine Hyvä-Migration Sie enttäuschen: Sie bezahlen eine neue Theme-Ebene und laden dann dasselbe störende Skript wieder hinein.

3. Ändern Sie das Design ohnehin?

Wenn ein Rebranding oder ein vollständiges Redesign ohnehin budgetiert ist, ändert sich die Rechnung völlig. Luma-Templates auf ein neues Design umzubauen kostet einen erheblichen Anteil dessen, was der Aufbau in Hyvä kostet — und am Ende steht der langsame Stack. Wenn Designarbeit ohnehin auf der Roadmap steht, ist Hyvä meist die richtige Antwort, selbst wenn Performance allein sie nicht gerechtfertigt hätte.

4. Wie sieht Ihr Extension-Bestand aus?

Zählen Sie jede Extension, die etwas rendert, das ein Kunde sieht. Prüfen Sie für jede, ob es eine Hyvä-kompatible Version gibt, ob der Anbieter noch aktiv ist und ob Sie die Funktion überhaupt noch nutzen. Nach unserer Erfahrung migriert ein Shop mit weniger als etwa fünfzehn storefront-seitigen Extensions problemlos; jenseits von dreißig dominiert die Kompatibilitätsarbeit das Projekt, und die Schätzung muss das abbilden.

5. Brauchen Sie wirklich ein eigenes Frontend?

Eine PWA rechtfertigt sich durch Anforderungen, die das Templating von Magento nicht erfüllen kann — eine Storefront für mehrere Backends, App und Web mit gemeinsamer Codebasis, eine Customer Journey, die wirklich einer Anwendung gleicht statt einem Katalog, oder eine Roadmap, die den Abschied von Magento vorsieht. Der Wunsch nach einem modernen JavaScript-Stack ist keine Anforderung. Er ist eine Präferenz, und aus dem Storefront-Budget ist sie teuer.

Wenn eine Headless-Architektur wirklich Ihr Ziel ist, lohnt der Vergleich zwischen dem, was Sie auf Magento bauen würden, und einer eigens dafür gebauten Headless-Engine — diesen Vergleich legen wir in unserer Arbeit zur Plattformauswahl dar.

6. Können Sie sich die falsche Antwort leisten?

Eine gescheiterte Luma-Optimierung kostet Sie ein paar Wochen. Eine gescheiterte Hyvä-Migration kostet Sie ein Quartal und viel Wohlwollen. Ein gescheitertes PWA-Projekt hat schon Karrieren beendet. Gewichten Sie die Optionen danach, was passiert, wenn das Projekt schlecht läuft — nicht nur danach, was passiert, wenn es gut läuft.

Wann wir Kunden raten, auf Luma zu bleiben

Das ist der Teil des Gesprächs, den Pitch Decks auslassen, deshalb hier klar benannt. Wir empfehlen, auf Luma zu bleiben, wenn:

• Die Core Web Vitals im Feld bereits bestanden werden und der Druck von einem synthetischen Score kommt, nicht von echten Besuchern
• Der Shop auf einer Magento-Version läuft, die zuerst aktualisiert werden muss — erst das Plattform-Upgrade, dann erneut messen, dann entscheiden
• Ein Replatforming auf der Zwei-Jahres-Roadmap steht — geben Sie keine sechsstellige Summe für ein Frontend aus, das Sie ohnehin abschalten wollen
• Der Extension-Bestand riesig und überwiegend individuell ist und die Kompatibilitätsarbeit den Wert des Geschwindigkeitsgewinns übersteigen würde
• Der eigentliche Engpass serverseitig liegt — eine langsame Time to First Byte aus einer unterdimensionierten Datenbank oder einem kalten Cache ist kein Theme-Problem, und kein Frontend wird sie verdecken
• Die Geschäftslage das Risiko derzeit unvertretbar macht — niemand sollte eine Storefront sechs Wochen vor der Hochsaison migrieren

Der letzte Punkt wiegt schwerer, als Händler erwarten. Wir haben Migrationsprojekte im September mehr als einmal abgelehnt. Das richtige Projekt zur falschen Zeit bleibt das falsche Projekt.

Die Amortisationsrechnung aufstellen

Welche Option Sie auch wählen, der Business Case ist dieselbe Rechnung. Sie brauchen vier Zahlen, und drei davon haben Sie bereits.

1. Sitzungen pro Monat auf den Templates, die Sie ändern wollen — nicht für die gesamte Website, nur für die betroffenen Templates
2. Aktuelle Conversion Rate auf diesen Templates, aufgeschlüsselt nach Gerät, denn die Lücke liegt fast immer auf dem Smartphone
3. Durchschnittlicher Bestellwert, ebenfalls auf diesen Templates
4. Erwarteter Conversion-Zuwachs — das ist die einzige Schätzung, und sie sollte konservativ ausfallen

Bei dieser vierten Zahl sollten Sie jedem misstrauen, der Ihnen einen Prozentwert ohne Einschränkung nennt. Ehrlich ist: Geschwindigkeitsgewinne korrelieren mit besseren Conversions, der Effekt ist auf Mobilgeräten und bei langsameren Verbindungen größer, und seine Höhe schwankt je nach Kategorie und Warenkorbwert enorm. Rechnen Sie einen konservativen und einen optimistischen Fall — und entscheiden Sie auf Basis des konservativen.

Teilen Sie dann die Projektkosten durch den monatlichen Rohertragszuwachs im konservativen Fall. Liegt die Amortisationszeit unter zwölf Monaten, ist der Business Case stark. Zwölf bis vierundzwanzig Monate sind vertretbar, wenn die Storefront noch andere Aufgaben erfüllen soll — ein Redesign, einen B2B-Kanal, einen neuen Markt. Jenseits von vierundzwanzig Monaten im konservativen Fall kaufen Sie etwas anderes als eine Rendite.

Was jede Option im Betrieb wirklich kostet

Die Baukosten sind die Zahl, die alle vergleichen. Die Betriebskosten sind die Zahl, die entscheidet, ob Sie die Wahl bereuen.

Luma kostet im Besitz nichts extra und in der Wartung alles: Jede neue Extension kann das JavaScript-Gewicht zurückbringen, für dessen Entfernung Sie bezahlt haben — Performance-Arbeit wird damit zu einem wiederkehrenden Posten statt zu einem Projekt.

Hyvä bringt eine jährliche Lizenz und einen moderaten laufenden Kompatibilitätsaufschlag mit — neue Extensions brauchen Hyvä-kompatible Versionen, und die Auswahl ist kleiner. Dafür sind Performance-Rückschritte deutlich seltener, weil es viel weniger Maschinerie gibt, die zurückfallen kann.

Eine PWA kostet Sie dauerhaft eine zweite Anwendung: eigenes Hosting, eigene Deployments, eigene Abhängigkeits-Updates, eigenes Sicherheits-Patching und Frontend-Kompetenz, die Ihr Team halten muss. Kalkulieren Sie ein laufendes Entwicklungsbudget, keine Wartungspauschale. Das ist der Kostenblock, den die meisten PWA-Business-Cases auslassen — und der im zweiten Jahr zuschlägt.

Eine sinnvolle Reihenfolge

Für die meisten Magento-Händler ist die richtige Reihenfolge wenig spektakulär:

1. Auf eine aktuelle, unterstützte Magento-Version wechseln — alles Weitere ist auf 2.4.9 einfacher und günstiger
2. Den Extension-Bestand prüfen und ausdünnen; abschalten, was niemand nutzt, und ersetzen, was sich nicht schnell bekommen lässt
3. Die serverseitige Arbeit erledigen — Cache-Trefferquoten, Datenbank-Tuning, Bild-Pipeline, Hosting-Profil
4. Die Core Web Vitals im Feld erneut messen und sehen, was tatsächlich übrig bleibt
5. Dann entscheiden, ob der verbleibende Abstand eine Frontend-Migration rechtfertigt

Händler, die dieser Reihenfolge folgen, stellen manchmal fest, dass die Migration unnötig ist. Wer direkt zu Schritt fünf springt, stellt es manchmal erst fest, nachdem er dafür bezahlt hat.

Wenn Sie eine zweite Meinung dazu möchten, wo Ihr Shop tatsächlich steht: Unser Magento-Entwicklungsteam übernimmt die Messung und sagt Ihnen ehrlich, welche der drei Antworten Ihre Daten stützen — auch dann, wenn es noch keine davon ist. Dieselbe Disziplin gilt für unsere Magento-Plattformarbeit, und für Marken im Einzelhandel zahlt sie sich meist im ersten Quartal nach dem Launch aus.

Erst messen, dann das Angebot einholen

Das Nützlichste, was Sie tun können, bevor Sie irgendetwas ausgeben, ist herauszufinden, welche Ihrer Probleme Theme-Probleme sind. Wir führen dieses Audit durch und geben Ihnen die ehrliche Antwort — auch wenn sie lautet, dass Sie uns nicht brauchen. Sprechen Sie mit unserem Team — wir antworten innerhalb eines Werktags.