Magento Storefront entkoppeln, Backend behalten

Was Headless für einen Magento-Shop bedeutet

Eine klassische Magento-Installation koppelt das Frontend direkt an das Backend. Luma oder Hyva rendert server-seitiges HTML über Magento's PHP-Schicht, einschliesslich aller Geschäftslogik. Jeder Seitenaufruf löst Magento's vollständigen Request-Lifecycle aus: PHP-Bootstrap, Layout-Rendering, Block-Rendering, Template-Rendering.

Bei einer Headless-Architektur trennt man diese Kopplung auf. Magento läuft als API-first Backend. Es verwaltet:

• ▸Produktkatalog: Attribute, Kategorien, konfigurierbare und gruppierte Produkte
• ▸Auftragsmanagement: Checkout-Ablauf, Bestellstatus, Retouren
• ▸Bestandsverwaltung: MSI-Quellen, verkaufbare Menge pro Lager
• ▸Kundenkonten: Bestellhistorie, Adressen, Wunschliste
• ▸Aktionen und Preisregeln: Katalog- und Warenkorbregeln
• ▸Zahlungsintegrationen: Mollie, Stripe und andere über Magento Payment Provider

Das Next.js Frontend ruft Daten über die Magento GraphQL API ab und rendert den Storefront als statische oder server-gerenderte React-Seiten. Besucher sehen nie Magento's PHP-Schicht. Sie sehen HTML, das in Millisekunden über Next.js Server Components oder Edge-Rendering generiert wurde.

Wann Headless für Ihren Magento-Shop sinnvoll ist

Headless ist keine Standardwahl. Es fügt der Architektur Komplexität hinzu, und diese Komplexität muss etwas liefern. Die folgenden Situationen rechtfertigen diese Investition:

• ▸LCP-Decke beim klassischen Storefront: Luma-Shops erreichen auf Mobilgeräten regelmässig 8 bis 14 Sekunden PSI-Labor-LCP. Hyva bringt das auf 3 bis 5 Sekunden. Next.js auf Magento GraphQL erreicht 0,6 bis 1,2 Sekunden in CrUX für Produktseiten mit korrekter Bildpriorisierung.
• ▸Multi-Channel ohne Adobe Commerce Lizenz: Sie möchten denselben Katalog über einen Webshop, eine mobile App und ein B2B-Portal bereitstellen. Mit Magento als API-Backend haben Sie eine Datenschicht für alle Kanäle, ohne Commerce-Lizenz.
• ▸Team mit React-Expertise: Ihre Frontend-Entwickler arbeiten täglich in React. Sie sind produktiver in Next.js als im Magento-Templatesystem, LESS und RequireJS.
• ▸Designfreiheit über Hyva hinaus: Hyva ist schnell, bleibt aber ein Magento-Theme. Wenn das Design erheblich von dem abweicht, was ein Theme leisten kann, ist Headless der kürzere Weg.
• ▸PWA Studio als zu komplex eingestuft: Magento's eigenes PWA Studio hat eine steile Lernkurve und begrenzten Community-Support. Next.js ist für die meisten React-Entwickler vertrauter.

Es geht nicht um Trendempfindlichkeit. Es geht darum, ob die Komplexität einer Headless-Architektur etwas Konkretes für Ihre spezifische Situation liefert.

Wann Headless keine gute Wahl ist

Ich empfehle Headless nicht jedem. Es gibt Situationen, wo es mehr kostet als es bringt:

• ✕Kleiner Katalog mit weniger als 500 Produkten: Hyva Themes erreicht hier bereits hervorragende Performance. Die zusätzliche Architekturschicht bringt dem Besucher keinen sichtbaren Mehrwert.
• ✕Keine Frontend-Entwicklungskapazität: ein Headless-Storefront erfordert laufende Frontend-Pflege durch Entwickler, die React und Next.js kennen. Ohne dieses Team wird die Pflege zum Engpass.
• ✕Zahlungsanbieter, die fest an den Magento-Storefront koppeln: einige Zahlungsanbieter integrieren über Magento-Module, die direkten Zugriff auf das PHP-Frontend benötigen. Das lässt sich umgehen, erfordert aber zusätzliche Arbeit pro Anbieter.
• ✕Kleine Budgets ohne Wachstumspfad: Headless-Migrationen sind substanziell. Wenn der Business Case nicht klar ist, ist eine Hyva-Migration oft der bessere erste Schritt.
• ✕Magento-Funktionalität, die stark auf Drittanbieter-Module mit eigenem Frontend setzt: Erweiterungen wie Amasty Page Builder oder benutzerdefinierte Checkout-Module sind für den Magento-Storefront gebaut. Sie integrieren sich nicht automatisch in ein Headless-Frontend.

Wenn ich daran zweifle, ob Headless die richtige Wahl für Ihre Situation ist, sage ich das. Ein Architektur-Audit kostet weniger als eine Migration, die auf halbem Weg stecken bleibt.

Die Architektur, die ich baue

Für Headless Magento verwende ich einen festen Satz von Entscheidungen, basierend auf dem, was in der Produktion funktioniert:

• ▸Next.js App Router: Server Components für statische und server-gerenderte Seiten, Client Components nur wo Interaktion benötigt wird. Kein unnötiges JavaScript wird an den Browser gesendet.
• ▸Magento GraphQL API: Produktkatalog, Kategorienavigation, Warenkorb-Operationen, Checkout, Kundenkonto und Bestellhistorie über die Magento GraphQL-Schicht. REST nur wo GraphQL nicht ausreicht.
• ▸Algolia für die Suche (optional): Magento's eingebaute Katalogsuche skaliert bei grossen Katalogen nicht gut. Algolia synchronisiert den Katalog und liefert Sofortsuche mit facettierter Filterung.
• ▸Mollie oder Stripe über Magento Order API: Zahlung läuft über das Magento-Backend. Next.js sendet die Bestellung an Magento, Magento verarbeitet den Zahlungsanbieter. Der Besucher sieht ein React-Checkout-Formular, die Zahlung läuft über den bestehenden Magento-Zahlungsanbieter.
• ▸ISR für Produktseiten: Incremental Static Regeneration für Produktseiten stellt sicher, dass statisches HTML am Edge verfügbar ist, ohne dass jeder Besucher einen GraphQL-Aufruf auslöst.
• ▸Cloudflare Workers für Traffic-Aufteilung während der Migration: Headless und Classic laufen parallel, Cloudflare leitet einen konfigurierbaren Prozentsatz des Traffics an das neue Frontend weiter.

Jede dieser Entscheidungen ist diskutierbar. Wenn Ihr Team Elasticsearch gegenüber Algolia bevorzugt oder Ihr Zahlungsanbieter eine abweichende Integration erfordert, passe ich die Architektur an.

Wie die Migration verläuft

Headless-Migrationen sind riskant, wenn sie auf einmal live gehen. Ich verwende eine parallele Deploy-Strategie, die Ausfallzeiten und Risiken minimiert.

Das neue Next.js Frontend wird neben dem bestehenden Magento-Storefront aufgebaut. Beide laufen auf demselben Magento 2 Backend. Über einen Cloudflare Worker arrangiere ich Traffic-Aufteilung: zunächst 5 Prozent des Traffics zum neuen Frontend, dann 20 Prozent, dann 50 Prozent. Jeder Schritt wird auf Konversion, Fehlerquoten und Core Web Vitals überwacht. Wenn ein Schritt Probleme zeigt, kehrt der Traffic sofort zum Classic-Storefront zurück, ohne dass Besucher etwas bemerken.

Nach dem harten Cutover bleibt der Classic Magento-Storefront als Fallback erhalten. Erst nach einer stabilen Phase, sobald alle Randfälle behoben sind, wird der Classic-Storefront abgeschaltet. Magento Admin Panel, Erweiterungen und Auftragsmanagement bleiben während der gesamten Migration unberührt.

Was ich nicht mache

Headless-Migrationen werden manchmal als Lösung verkauft, ohne dass die Problemdiagnose stimmt. Ich mache Folgendes nicht:

• ✕Magento PWA Studio Implementierungen ohne guten Grund: PWA Studio ist Magento's eigenes Headless-Framework, hat aber im Vergleich zu Next.js eine kleinere Entwickler-Community. Ich verwende es nur, wenn das Team bereits damit arbeitet.
• ✕Headless ohne umfassendes Architektur-Audit: ein Headless-Frontend auf einem schlecht konfigurierten Magento-Backend löst die Backend-Probleme nicht. TTFB von 2 Sekunden bei GraphQL-Aufrufen untergräbt jeden Frontend-Gewinn.
• ✕Framework-Entscheidung für das Kundenteam treffen: wenn Ihr Team mit Nuxt, Remix oder einem anderen React-Framework arbeitet, behaupte ich nicht, dass Next.js die einzig richtige Wahl ist. Ich mache die Trade-offs klar.
• ✕Migrationen ohne Fallback-Strategie: eine Headless-Migration ohne paralleles Deploy ist ein unnötiges Risiko. Ich baue immer einen Rückweg ein.

Wenn eine Architekturentscheidung nicht zu Ihrer Situation passt, sage ich das direkt. Eine Migration, die auf halbem Weg stecken bleibt, kostet mehr als die Migration selbst.

Verwandte Seiten