Einen Magento 2 E-Commerce auf 15 Stores und 9 Sprachen zu skalieren — und das aus einer einzigen Instanz heraus — ist kein Gedankenexperiment. Es ist ein reales Projekt, das wir für Loviux umgesetzt haben, einen europaweit tätigen E-Commerce im Bereich Intimate Wellness. Dieser Artikel dokumentiert die technischen Entscheidungen, die Probleme, auf die wir gestoßen sind, und wie wir sie gelöst haben.
Wenn Sie mit Magento in großem Maßstab arbeiten — als CTO, Tech Lead oder Senior Developer — finden Sie hier unsere Erfahrungen aus der Migration von Luma zu Hyvä, dem Aufbau eines Custom-Checkouts ohne schwere Frameworks, der automatisierten Inhaltsgenerierung für über 9.000 Produkte und dem Betrieb eines Performance-Stacks, der beim Deployment nicht ausfällt.
Warum die Migration von Luma zu Hyvä (und was sich wirklich ändert)
Luma war jahrelang das Standard-Frontend von Magento 2. Und genauso lange war es dessen größte technische Altlast.
Die tatsächlichen Kosten von Luma
Der technische Stack von Luma basiert auf RequireJS für die Modulverwaltung und Knockout.js für Data Binding. Beide Technologien stammen aus dem Jahr 2013 und wurden von Magento übernommen, aber nie modernisiert. Die praktischen Auswirkungen in einem Projekt mit 15 Stores:
- RequireJS erzeugt eine Kaskade von HTTP-Anfragen, die das Rendering blockiert. In einem Katalog mit Tausenden von Produkten lud jede Seite zwischen 40 und 60 JavaScript-Dateien, bevor sie interaktiv wurde.
- Knockout.js bringt Gewicht, ohne Mehrwert zu liefern. Für einen E-Commerce, dessen tatsächliche Interaktivität sich auf Warenkorb, Filter und Checkout beschränkt, ist ein vollständiges Data-Binding-Framework Overengineering.
- Das CSS von Luma wiegt ca. 300 KB unkomprimiert. Jede Anpassung fügt Schicht um Schicht an LESS-Code hinzu, den niemand zu refaktorisieren wagt.
In unseren Tests benötigte eine Kategorieseite unter Luma 4,2 Sekunden für den LCP (Largest Contentful Paint) auf Mobilgeräten. Inakzeptabel für einen E-Commerce, bei dem laut Google-Daten jede zusätzliche Sekunde Ladezeit die Conversion-Rate um 7 % senkt.
Was Hyvä + Tailwind CSS bringen
Hyvä ersetzt das gesamte Luma-Frontend durch eine moderne Architektur: Alpine.js für Interaktivität, Tailwind CSS für Styling und null Legacy-Abhängigkeiten.
Die Kennzahlen nach der Migration:
Das ist keine inkrementelle Verbesserung. Es ist eine Veränderung um eine Größenordnung. Und in einem Multi-Store mit 15 Shops multipliziert sich dieser Unterschied: weniger Serverressourcen pro Request, besseres Caching, bessere Nutzererfahrung in jeder der 9 Sprachen.
Die Migration war nicht trivial. Jedes Drittanbietermodul, das Luma verwendete (und wir hatten über 30), benötigte entweder ein Compatibility-Modul für Hyvä oder einen vollständigen Ersatz. Wir dokumentierten jede Abhängigkeit vor Projektbeginn und priorisierten nach geschäftlicher Relevanz. Module, die nur das Admin-Panel betrafen, erforderten keine Änderungen; solche mit Frontend-.phtml-Templates schon.
Multi-Store im großen Maßstab: 15 Shops, 9 Sprachen, eine Instanz
Magento unterstützt Multi-Store nativ, aber die Realität der Verwaltung in dieser Größenordnung ist eine andere Sache.
Architektur von Websites, Stores und Store Views
Das Setup von Loviux hat drei Ebenen:
- Websites: Gruppierung von Shops nach Preiszonen und Steuerregeln (EU Süd, EU Nord, UK)
- Stores: einer pro Land (Deutschland, Frankreich, Spanien, Italien, Niederlande, Portugal, Polen, Österreich, Schweiz, Belgien, Vereinigtes Königreich und weitere Varianten)
- Store Views: die Sprachebene. Ein Store kann mehrere Views haben (die Schweiz hat 3: DE, FR, IT; Belgien hat 2: NL, FR)
Insgesamt 15 Store Views, die Inhalte in 9 Sprachen ausliefern: Spanisch, Englisch, Portugiesisch, Französisch, Deutsch, Italienisch, Niederländisch, Polnisch sowie regionale Varianten.
Eigenes Sprach-Fallback-System
Hier trafen wir auf die erste echte Herausforderung. Magento verfügt über ein rudimentäres Fallback-System für Übersetzungen, löst aber das Problem der Kataloginhalte nicht.
Das Problem: Wenn ein Produkt keine ins österreichische Deutsch (de_AT) übersetzte Beschreibung hat, zeigt Magento ein leeres Feld an. Es fällt nicht automatisch auf Standarddeutsch (de_DE) zurück. Das bedeutet: Ohne ein Fallback-System müssen Sie jedes Produkt einzeln für jede Locale übersetzen — auch für Varianten, die sich eine Sprache teilen.
Unsere Lösung: Wir entwickelten ein Plugin, das das Laden lokalisierter Attribute abfängt und eine konfigurierbare Fallback-Kette anwendet:
Das Ergebnis: Ländervarianten erben automatisch die Inhalte der Hauptsprache. Sie übersetzen nur einmal pro Sprache, und regionale Unterschiede (Preise, Verfügbarkeit, rechtliche Texte) werden auf Store-Ebene verwaltet, ohne den gesamten Katalog zu duplizieren.
Dieser Mechanismus reduzierte den Übersetzungsaufwand um 65 % und eliminierte das Risiko, dass Tausende von Produkten mit leeren Feldern in Sekundär-Stores erscheinen.
Custom Checkout mit Magewire und Alpine.js
Der Checkout ist die Stelle, an der ein E-Commerce Geld verdient oder verliert. Der Standard-Checkout von Magento 2 (basierend auf Knockout.js + UI Components) ist funktional, aber schwerfällig, langsam und schwer anzupassen.
Warum wir React und Knockout verworfen haben
Wir evaluierten drei Optionen:
- Standard-Luma-Checkout: verworfen, weil wir auf Hyvä migrierten und Knockout ausschließlich für den Checkout beizubehalten inkonsistent gewesen wäre.
- Checkout mit React (wie Hyvä Checkout): bringt eine zusätzliche Abhängigkeit von ca. 130 KB und eine separate Build-Pipeline mit. Für ein dreistufiges Formular unverhältnismäßig.
- Magewire + Alpine.js: derselbe Stack wie der Rest von Hyvä. Keine zusätzlichen Abhängigkeiten, keine separate Build-Pipeline, keine State-Konflikte zwischen Frameworks.
Wir entschieden uns für Magewire. Es handelt sich um eine Portierung von Laravel Livewire für Magento, die interaktive Komponenten mit PHP auf dem Server und Alpine.js auf dem Client ermöglicht. Das Ergebnis ist ein Checkout, der weniger als 15 KB JavaScript wiegt (ohne Alpine, das bereits global geladen ist).
Drei-Spalten-Layout
Wir gestalteten den Checkout als Drei-Spalten-Layout auf dem Desktop:
- Linke Spalte: Lieferadresse und Kundendaten
- Mittlere Spalte: Versand- und Zahlungsmethoden
- Rechte Spalte: Bestellübersicht, Gutscheine, Gesamtbeträge
Alle drei Bereiche werden serverseitig mit Magewire gerendert und per AJAX aktualisiert, wenn Nutzer Daten ändern. Keine SPA, kein Client-Router, kein geteilter State zwischen Frameworks. Jede Magewire-Komponente ist eigenständig und kommuniziert direkt mit dem Backend.
Auf Mobilgeräten klappen die Spalten zu einem vertikalen Ablauf mit Akkordeons zusammen. Derselbe Code, ohne Duplizierung und ohne komplexe Layout-Media-Queries.
Ergebnis: Der Checkout lädt in 1,1 Sekunden auf Mobilgeräten (LCP), und die Abbruchrate im Zahlungsschritt sank um 12 % gegenüber dem vorherigen Luma-Checkout.
Katalog mit über 60.000 Produkten und erweiterter Suche
Ein Katalog dieser Größe braucht mehr als die native Magento-Suche (MySQL FULLTEXT). Er braucht schnelle und relevante facettierte Suche. Ein Blick in den Vibratoren-Katalog verdeutlicht die Dimension.
SmileElasticSuite mit OpenSearch
Wir implementierten SmileElasticSuite, die ausgereifteste Open-Source-Suchlösung für Magento, angebunden an OpenSearch 2.x als Indexierungsengine.
Zentrale Konfigurationspunkte:
- Facettierte Suche mit dynamischen Filtern pro Kategorie: Die verfügbaren Filter ändern sich je nach aktueller Kategorie (Größe, Farbe, Material, Marke, Preisspanne)
- Autocomplete mit Vorschlägen für Produkte, Kategorien und Suchbegriffe
- Synonyme pro Sprache: konfiguriert pro Store View, sodass beispielsweise „Gleitgel" und „Intimgel" dieselben Ergebnisse liefern
- Angepasste Relevanz: Produkte mit Lagerbestand, mit Bild und mit Bewertungen werden gegenüber anderen bevorzugt
Die vollständige Neuindexierung des Katalogs (60.000+ Produkte × 9 Sprachen) dauert 8 Minuten mit einem dedizierten Cron-Job. Inkrementelle Aktualisierungen (Preis, Bestand) werden in weniger als 30 Sekunden verarbeitet.
Bestandssynchronisation mit Lieferanten
Loviux arbeitet mit mehreren Lieferanten, die Bestandsfeeds in heterogenen Formaten senden: XML, CSV und in einem Fall ein proprietärer JSON-Endpunkt.
Wir entwickelten ein modulares Importsystem:
- Parser pro Lieferant: Jeder Lieferant hat einen Adapter, der seinen Feed in das interne Format normalisiert (SKU, Menge, Einkaufspreis, voraussichtliche Lieferzeit)
- Tägliche geplante Ausführung: Ein Magento-Cron führt die Synchronisation jede Nacht um 3:00 Uhr morgens aus (zur Stunde mit geringstem Traffic)
- Logs und Benachrichtigungen: Wenn ein Lieferant keinen Feed sendet oder sich das Format ändert, wird das Team per E-Mail benachrichtigt
- Aggregierter Bestand: Bei Dropship-Produkten ist der angezeigte Bestand die Summe aller Lieferanten, die das Produkt führen
Dieses System verarbeitet jede Nacht ca. 15.000 Bestandszeilen, ohne die Frontend-Performance zu beeinträchtigen.
KI-gestützte Content-Pipeline: 9.000 Produkte in 9 Sprachen
Dies war möglicherweise die interessanteste Herausforderung des Projekts. Mit über 9.000 Produkten, die Beschreibungen in 9 Sprachen benötigen, sprechen wir von 81.000 Produkttexten. Dies manuell zu bewältigen, ist weder wirtschaftlich noch zeitlich vertretbar.
Die vierstufige Pipeline
Wir entwickelten eine automatisierte Pipeline mit GPT-4o-mini (gewählt aufgrund des optimalen Kosten-Qualitäts-Verhältnisses für Massengenerierung):
Schritt 1 — Feature-Extraktion: Wir lesen die technischen Datenblätter des Herstellers aus (Bezeichnung, Inhaltsstoffe, Volumen, Produkttyp, besondere Eigenschaften) und strukturieren sie als normalisiertes JSON.
Schritt 2 — Native Generierung pro Sprache: Anstatt auf Spanisch zu generieren und dann zu übersetzen, generieren wir direkt in jeder Zielsprache. Der Unterschied ist erheblich: Ein nativ auf Deutsch generierter Text klingt natürlich; ein aus dem Spanischen übersetzter Text klingt nach Übersetzung. Der Prompt enthält Markenkontext, Tonalität und rechtliche Einschränkungen des Zielmarktes.
Schritt 3 — Bereinigung: Wir entfernen generische, sich wiederholende Phrasen, korrigieren Inkonsistenzen zwischen Sprachen (ein Produkt kann nicht in Deutschland „150 ml" und in Frankreich „5 oz" sein, wenn europaweit in Millilitern verkauft wird) und wenden Stilregeln an.
Schritt 4 — Automatische Validierung: Jeder generierte Text durchläuft Prüfungen auf Mindest-/Maximallänge, Vorhandensein von Produkt-Keywords, Abwesenheit von Halluzinationen (erfundene Inhaltsstoffe, falsche Eigenschaften) und korrektes HTML-Format für Magento.
Kennzahlen der Pipeline
- Gesamtkosten: ca. 420 € an API-Tokens für alle 81.000 Texte
- Verarbeitungszeit: 14 Stunden für die vollständige Generierung
- Automatische Freigabequote: 87 % der Texte bestanden die Validierung ohne manuelle Eingriffe
- Manuelle Nachbearbeitung: Die restlichen 13 % erforderten kleinere Anpassungen (hauptsächlich Produkte mit Sondereigenschaften, die in den Herstellerdaten nicht abgedeckt waren)
Im Vergleich zu professioneller Übersetzung (geschätzt auf über 120.000 € und 4–6 Monate) bedeutete die KI-Pipeline eine Kostenersparnis von 99,6 % und eine Zeitersparnis von 95 %. Die Qualität erreicht nicht das Niveau eines Senior-Copywriters, ist aber für funktionale, SEO-taugliche Produktbeschreibungen mehr als ausreichend.
Performance-Stack: Varnish, Redis, OPcache und PHP 8.4
Das Ergebnis spricht für sich: PageSpeed Insights 100 auf Mobilgeräten für einen Magento 2 Shop mit 15 Store Views und über 60.000 Produkten. FCP von 1,4 Sekunden, LCP von 1,5 Sekunden, TBT von 30 ms und CLS von 0. Diese Werte sind für jede E-Commerce-Plattform außergewöhnlich — umso mehr für eine auf Magento basierende.
Performance ist in einem E-Commerce keine Option. Ein langsamer Shop verliert Umsatz. Mit 15 Stores, die Traffic aus ganz Europa bedienen, muss der Stack belastbar sein.
Cache-Architektur
Die Magento-Entwicklungs-Konfiguration, die wir für Loviux aufgebaut haben, folgt einer vierschichtigen Hierarchie:
- Varnish 7.x als Reverse Proxy: cached vollständige Seiten. Ein Varnish-Hit liefert eine Seite in unter 10 ms, ohne PHP zu berühren. Wir konfigurierten Custom-VCL für selektives Purging nach Store View, Kategorie und Produkt.
- Redis für Anwendungscache und Sessions: eliminiert Festplattenzugriffe. Zwei getrennte Instanzen — eine für Konfigurations-/Block-Cache (DB 0), eine für Sessions (DB 2).
- OPcache von PHP 8.4: kompiliert die ca. 40.000 PHP-Dateien von Magento vor. Mit aktiviertem
opcache.jit=tracingwerden Hot-Path-Funktionen zu nativem Maschinencode kompiliert. - Full-Page-Cache in Magento als Fallback für Requests, die Varnish umgehen (eingeloggte Nutzer, nicht leerer Warenkorb).
Blocking CSS: eine kontraintuitive Entscheidung für CLS 0
Die gängige Empfehlung lautet: CSS asynchron laden, Critical CSS inline extrahieren. Wir machten das Gegenteil. Das gesamte CSS wird blockierend im <head> geladen.
Warum? Weil mit Hyvä + Tailwind das gesamte CSS ca. 35 KB wiegt (gzipped: ca. 8 KB). Es blockierend zu laden, fügt wenige Millisekunden zum First Contentful Paint hinzu, garantiert aber, dass sich das Layout nach dem ersten Render nie verändert. Das Ergebnis: ein CLS (Cumulative Layout Shift) von 0,000 — konsistent auf allen Seiten.
In einem Projekt mit Dutzenden verschiedener Templates (Startseite, Kategorie, Produkt, Checkout, CMS-Seiten × 15 Stores) wäre die Pflege eines synchronisierten Critical-CSS-Systems ein Wartungsalptraum. Bei 8 KB blockierendem CSS ergibt dieser Kompromiss keinen Sinn.
Zero-Downtime-Deployment mit Symlink-Switching
Das Deployment in der Produktivumgebung folgt einem Ablauf, der Ausfallzeiten vermeidet:
- Build in einem temporären Verzeichnis (
/var/www/releases/YYYYMMDD-HHMMSS/) composer install --no-dev,bin/magento setup:di:compile,bin/magento setup:static-content:deployfür alle 9 Sprachen- Cache-Warmup: Wir führen Requests auf Schlüsselseiten aus, um Varnish zu befüllen
- Atomarer Symlink-Switch:
ln -sfnändert den Symlink/var/www/currentauf das neue Release php-fpm reload, damit die Worker den neuen Code laden- Selektives Purging von Varnish
Wenn etwas schiefgeht, bedeutet ein Rollback lediglich das Umschalten des Symlinks auf das vorherige Release. Ausfallzeit: 0 Sekunden.
Das setup:static-content:deploy für 9 Sprachen dauert ca. 12 Minuten. Es ist der langsamste Schritt in der Pipeline, aber da er vor dem Switch ausgeführt wird, beeinträchtigt er den Live-Traffic nicht.
Technisches SEO für mehrere Sprachen
Ein E-Commerce mit 15 Stores und 9 Sprachen ist ein Minenfeld für technisches SEO. Google muss verstehen, welche Seite für welches Land und welche Sprache bestimmt ist, ohne Varianten zu verwechseln.
Hreflang auf allen Seiten
Jede Seite enthält Hreflang-Tags, die auf alle ihre Varianten verweisen:
Das sind 14 Hreflang-Tags pro Seite. Bei einem Katalog von 60.000 Produkten bedeutet das 168.000 Hreflang-Deklarationen allein für Produktseiten. Wir generieren diese dynamisch mit einem Modul, das die URL-Rewrites von Magento pro Store View abfragt.
Vollständige strukturierte Daten
Wir implementierten Schema.org JSON-LD auf allen relevanten Seiten:
- Product: mit
offers,aggregateRating,brand,sku,gtin13(sofern verfügbar). Google zeigt Rich Snippets mit Preis und Verfügbarkeit an. - CollectionPage: auf Kategorieseiten mit
numberOfItemsund Breadcrumb. - BreadcrumbList: vollständige hierarchische Navigation (Startseite → Kategorie → Unterkategorie → Produkt).
- Organization: Unternehmensdaten auf der Startseite und Kontaktseiten.
- FAQPage: auf Kategorieseiten mit produktbezogenen häufig gestellten Fragen.
Alles validiert mit dem Rich Results Test von Google und ohne Fehler in der Search Console.
Aufgeteilte Sitemaps nach Store
Eine einzelne Sitemap für 15 Stores würde das Limit von 50.000 URLs überschreiten. Wir generieren individuelle Sitemaps pro Store View:
loviux.de/sitemap.xml→ Sitemap-Index, der aufsitemap-products.xml,sitemap-categories.xml,sitemap-cms.xmlverweist- Dasselbe Schema für jede Domain (.es, .fr, .it, .nl, .pt, .pl, .co.uk, .at, .ch, .be, .com)
Jede Sitemap wird täglich um 5:00 Uhr morgens neu generiert und enthält <lastmod> basierend auf der tatsächlichen letzten Aktualisierung des Inhalts — nicht dem Generierungsdatum. Google schätzt ehrliche Timestamps.
Wichtige Integrationen
Brevo für E-Mail-Marketing
Wir verbanden Magento mit Brevo (ehemals Sendinblue) für die Automatisierung von Transaktions- und Marketing-E-Mails:
- Bidirektionale Kontaktsynchronisation (Registrierung, Kauf, Abbruch)
- Transaktions-E-Mails (Bestellbestätigung, Versand, Rechnung) über Brevo für bessere Zustellbarkeit
- Warenkorbabbrecher-Workflows, segmentiert nach Store und Sprache
GA4 Enhanced Ecommerce
Wir implementierten das vollständige GA4 Enhanced Ecommerce Tracking mit 10 Standard-Events:
view_item, view_item_list, add_to_cart, remove_from_cart, view_cart, begin_checkout, add_shipping_info, add_payment_info, purchase und refund.
Jedes Event enthält die Store-View-Dimension, um die Performance nach Land und Sprache in den Berichten segmentieren zu können.
Cloudflare Turnstile
Wir ersetzten reCAPTCHA durch Cloudflare Turnstile in allen Formularen: Registrierung, Login, Kontakt, Newsletter und Gast-Checkout. Turnstile zeigt dem Nutzer keine sichtbaren Challenges (es ist standardmäßig unsichtbar) und hat eine bessere Akzeptanzrate als reCAPTCHA v3. In einem E-Commerce ist jede zusätzliche Reibung im Checkout ein verlorener Verkauf.
Was wir aus diesem Projekt mitnehmen
Nach Monaten der Entwicklung, des Testens und der Optimierung sind dies die Erkenntnisse mit der größten Wirkung:
- Hyvä ist für neue Magento-2-Projekte keine Option, sondern Voraussetzung. Wer heute ein Projekt mit Luma startet, startet mit technischen Schulden. Der Leistungsunterschied ist zu gravierend.
- Das Sprach-Fallback-System wird entworfen, bevor das erste Produkt geladen wird. Es nachträglich bei 60.000 bereits eingepflegten Produkten umzusetzen, wäre ein Datenmigrationsalbtraum gewesen.
- Magewire ist die richtige Antwort für den Checkout in Hyvä. Dasselbe Paradigma wie der Rest des Frontends, ohne zusätzliche Abhängigkeiten. Laravel Livewire bewies das Konzept; Magewire bringt es nach Magento.
- KI für Produktinhalte ersetzt keine Texter, skaliert aber dort, wo menschliche Kapazitäten nicht ausreichen. 81.000 Texte in 9 Sprachen für 420 € — diese Gleichung lässt keinen Raum für Diskussion. Die menschliche Prüfung bleibt für die 10–15 % der Sonderfälle erforderlich.
- Blocking CSS mit Hyvä ergibt mehr Sinn als Critical CSS. Wenn Ihr gesamtes CSS weniger wiegt als ein Avatar-Bild, rechtfertigt die Komplexität eines Critical-CSS-Systems den Aufwand nicht.
- Zero-Downtime-Deployment ist Pflicht, kein Nice-to-have. Mit 15 Stores und Traffic rund um die Uhr aus mehreren Zeitzonen gibt es kein sicheres Wartungsfenster.
Wenn Ihr Unternehmen einen Magento 2 E-Commerce skalieren muss — sei es eine Migration zu Hyvä, ein Multi-Store-Setup oder komplexe Integrationen — kontaktieren Sie unser Team. Wir entwickeln seit über 15 Jahren E-Commerce-Lösungen, die im echten Betrieb bestehen.
