Was ist ein Magento-Frontend? Luma, Hyvä, PWA, Headless und FMP erklärt

Wenn du Adobe Commerce oder Magento 2 betreibst, sitzt die schwierigste Entscheidung selten im Backend. Der Katalog, der Warenkorb, die Preislogik und der Checkout sind gesetzt. Die eigentliche Frage lautet: Womit rendern wir das Storefront, das deine Kund:innen tatsächlich sehen? Genau das ist das Magento-Frontend, und dafür gibt es heute mehr als eine Antwort. Dieser Beitrag ordnet die fünf gängigen Optionen ein, Luma, Hyvä, PWA Studio, ein voll entkoppeltes Headless-Setup und eine Frontend Management Platform (FMP), zeigt die Trade-offs und erklärt, wann sich das Entkoppeln vom Backend lohnt.

Was ist ein Magento-Frontend, und warum ist die Wahl heute relevant?

Ein Magento-Setup besteht aus zwei Hälften. Das Backend ist die Commerce-Engine: Produktdaten, Warenkorb, Preise, Promotions, Steuern, Bestellungen. Das Frontend ist die Präsentationsschicht: die Seiten, Templates und Interaktionen, die im Browser landen. In einem klassischen Magento-Aufbau sind beide Hälften eng verdrahtet. Das Frontend wird serverseitig aus PHP-Templates gerendert, die direkt im selben Applikations-Stack liegen wie die Geschäftslogik.

Diese Kopplung war lange Standard, hat aber Konsequenzen. Ladezeiten, Developer Experience und die Geschwindigkeit, mit der dein Team neue Seiten und Kampagnen ausliefert, hängen fast vollständig an dieser Schicht. Seit Magento 2 haben sich deshalb mehrere Wege etabliert, das Frontend anders zu bauen, teils immer noch gekoppelt, teils vollständig entkoppelt. Die Wahl bestimmt, wie schnell dein Storefront ist, wie angenehm dein Team damit arbeitet und wie unabhängig du vom Release-Zyklus des Backends wirst.

Die fünf Frontend-Optionen im Überblick

Luma, das native Standard-Theme

Luma (und das darunterliegende Blank-Theme) ist das Frontend, das Magento von Haus aus mitbringt. Es rendert serverseitig über PHP, Layout-XML, PHTML-Templates, RequireJS und Knockout.js. Der Vorteil: Es ist da, es kennt jede Magento-Funktion, und praktisch jede Extension aus dem Marketplace ist darauf ausgelegt.

Der Preis dafür ist die Performance. Der Frontend-Stack ist schwer, die JavaScript-Bundles sind groß, und gute Core-Web-Vitals-Werte sind mit Luma harte Arbeit. Auch die Developer Experience ist eigen: Wer aus der modernen JavaScript-Welt kommt, findet Knockout.js und Layout-XML sperrig. Luma ist eine solide Wahl für kleinere Kataloge, enge Budgets oder Teams, die ohnehin tief im PHP-Magento-Ökosystem verankert sind.

Hyvä

Hyvä ist ein Ersatz-Theme, das den Luma-Frontend-Stack austauscht, ohne das Magento-Backend zu verlassen. Statt Knockout.js und RequireJS setzt Hyvä auf Tailwind CSS und Alpine.js und wirft den Großteil des mitgelieferten JavaScripts raus. Das Ergebnis sind deutlich schlankere Seiten und spürbar bessere Performance-Werte, oft ohne dass du deine Backend-Architektur anfassen musst.

Wichtig ist die Einordnung: Hyvä ist gekoppelt. Es rendert weiterhin serverseitig in Magento, es ersetzt nur die Frontend-Technologie. Das macht den Umstieg für bestehende Magento-Teams überschaubar und behält die Nähe zum Backend. Der Nachteil: Extensions, die für Luma gebaut sind, brauchen oft eine Hyvä-Kompatibilitätsschicht, und du bleibst an den Magento-Rendering-Pfad gebunden. Für viele mittelgroße Shops ist Hyvä heute der pragmatische Sweet Spot zwischen Performance und Aufwand.

PWA Studio

PWA Studio ist Adobes eigener Ansatz für ein entkoppeltes Frontend. Es ist ein React-basiertes Toolkit (Venia als Referenz-Storefront), das über die GraphQL-API von Magento mit dem Backend spricht. Das Frontend läuft als eigenständige Progressive Web App, getrennt vom PHP-Stack.

Damit bekommst du eine moderne JavaScript-Codebasis, App-artige Navigation und die Freiheit, das Frontend unabhängig zu deployen. Der Aufwand ist allerdings real: PWA Studio ist komplex, die Lernkurve steil, und die Community ist kleiner als rund um Hyvä. Du übernimmst außerdem die Verantwortung für Themen, die Luma dir abnimmt, etwa SEO-Rendering, Caching und das Nachbauen von Funktionen, die im nativen Theme einfach da sind. PWA Studio passt zu Teams mit React-Kompetenz, die bewusst ein entkoppeltes Adobe-natives Frontend wollen.

Fully headless

Voll headless bedeutet: Das Frontend ist ein komplett eigenständiges Projekt, das du frei wählst, etwa auf Basis von Next.js, Nuxt oder einem anderen modernen Framework, und Magento ist nur noch eine von mehreren Datenquellen dahinter. Die Kommunikation läuft über die GraphQL- oder REST-APIs. Anders als bei PWA Studio bist du nicht an Adobes Toolkit gebunden.

Das ist die flexibelste Variante. Du kannst das beste Framework für dein Team wählen, mehrere Backends kombinieren (etwa Magento für Commerce, ein separates CMS für Inhalte, eine Suche wie Algolia) und das Frontend unabhängig skalieren und ausliefern. Der Preis ist Verantwortung: Du baust und betreibst die gesamte Integrationsschicht, das Caching, das SEO-Rendering und die Datenorchestrierung selbst. Ein voll headless Projekt ist ein echtes Entwicklungsvorhaben, kein Theme-Wechsel. Es lohnt sich, wenn Differenzierung im Frontend, Multi-Backend-Anforderungen oder mehrere Touchpoints im Spiel sind.

Frontend Management Platform (FMP)

Eine Frontend Management Platform nimmt den Headless-Gedanken, das Frontend vom Backend zu entkoppeln, und legt eine Betriebs- und Redaktionsschicht darüber. Statt jede Integration, das Caching, das Rendering und den Editor selbst zu bauen, bekommst du diese Schicht als Produkt. Magento bleibt das Commerce-Backend, das Frontend wird entkoppelt gerendert, und dein Team stellt Seiten in einem visuellen Editor zusammen, statt für jede Änderung einen Deploy anzustoßen.

Der Unterschied zu reinem Headless liegt im Betrieb. Bei voll headless besitzt und wartet dein Team die komplette Frontend-Maschinerie. Eine FMP übernimmt die wiederkehrenden Teile, die Datenschicht, das Performance-Tuning, die Editor-Oberfläche, und lässt dein Team an Inhalten und Erlebnis arbeiten. Das ist der Ansatz hinter Laioutrs Composable Headless Frontend: die Vorteile der Entkopplung, ohne dass jedes Projekt bei null anfängt.

Vergleich: Trade-offs auf einen Blick

• Dimension | Luma | Hyvä | PWA Studio | Fully headless | FMP
• Kopplung zum Backend | Eng gekoppelt | Gekoppelt | Entkoppelt | Entkoppelt | Entkoppelt
• Performance-Potenzial | Niedrig | Hoch | Hoch | Sehr hoch | Sehr hoch
• Developer Experience | Knockout/XML | Tailwind/Alpine | React-Toolkit | Freie Wahl | Editor plus Framework
• Extension-Kompatibilität | Voll | Teilweise, Bridge nötig | Eingeschränkt | Selbst gebaut | Über Integrationsschicht
• Betriebsaufwand Frontend | Gering | Gering bis mittel | Hoch | Sehr hoch | Als Produkt abgedeckt
• Multi-Backend-fähig | Nein | Nein | Eingeschränkt | Ja | Ja
• Passt zu | Kleinen Katalogen | Mittleren Shops | React-Teams | Differenzierung | Teams ohne eigenen Frontend-Unterbau

Wann du das Frontend vom Backend entkoppeln solltest

Nicht jedes Setup muss entkoppelt werden. Ein kleiner Shop mit stabilem Katalog und knappem Budget ist mit Luma oder Hyvä oft besser bedient als mit einem eigenen Headless-Projekt. Die Entkopplung lohnt sich, wenn du eines der folgenden Muster erkennst.

Erstens: Die Frontend-Performance ist ein Geschäftsproblem und der gekoppelte Stack hält nicht mit, trotz Caching und Optimierung. Zweitens: Dein Team liefert zu langsam, weil jede Kampagne oder Landingpage an einem Deploy und am Release-Zyklus des Backends hängt. Drittens: Du brauchst mehr als ein Backend, etwa eine separate Suche, ein eigenes CMS oder mehrere Commerce-Systeme hinter einer Marke. Viertens: Du bedienst mehrere Touchpoints (Web, App, In-Store) aus derselben Datenschicht.

Wenn diese Muster auftreten, ist die nächste Frage nicht ob, sondern wie viel Frontend-Maschinerie du selbst besitzen willst. Voll headless gibt dir maximale Kontrolle bei maximaler Verantwortung. Eine FMP wie Laioutrs Composable Storefront gibt dir die Entkopplung, ohne dass dein Team die Integrations-, Caching- und Editor-Schicht von Grund auf baut und wartet.

FAQ

Ist Hyvä dasselbe wie Headless? Nein. Hyvä tauscht die Frontend-Technologie aus, rendert aber weiterhin serverseitig in Magento und bleibt an das Backend gekoppelt. Headless bedeutet, dass das Frontend ein eigenständiges Projekt ist, das über APIs mit Magento spricht.

Muss ich mein Magento-Backend wechseln, um zu entkoppeln? Nein. PWA Studio, ein voll headless Frontend und eine FMP sprechen alle über die GraphQL- oder REST-APIs mit deinem bestehenden Adobe Commerce oder Magento 2. Das Backend bleibt, nur die Präsentationsschicht wandert nach vorne.

Was ist der Unterschied zwischen PWA Studio und voll headless? PWA Studio ist Adobes eigenes React-Toolkit mit vorgegebenen Konventionen. Voll headless heißt, dass du Framework und Architektur frei wählst und Magento nur eine Datenquelle unter mehreren sein kann.

Wo passt eine Frontend Management Platform hinein? Eine FMP ist entkoppelt wie Headless, liefert aber die Betriebsschicht (Datenanbindung, Performance, visueller Editor) als Produkt mit. Sie passt zu Teams, die die Vorteile der Entkopplung wollen, ohne die komplette Frontend-Infrastruktur selbst zu bauen.

Was ist die schnellste Performance-Verbesserung ohne großes Projekt? Für die meisten gekoppelten Magento-Shops ist der Wechsel von Luma zu Hyvä der pragmatischste Schritt. Er verbessert die Performance spürbar, ohne die Backend-Architektur anzufassen.

Weitere Themen aus der Laioutr-Plattform

• Composable Headless Frontend: wie ein entkoppeltes Frontend auf Adobe Commerce oder Magento 2 aufsetzt, ohne dass dein Team die ganze Maschinerie selbst baut.
• Composable Storefront: das Storefront als eigenständige Schicht, die mehrere Backends bedienen kann.
• Frontend as a Service: die Betriebs- und Redaktionsschicht für ein entkoppeltes Frontend als Produkt.
• Agentic Frontend Management Platform: wie KI-Agenten Routine-Anpassungen am Frontend übernehmen.

Nächster Schritt

Willst du wissen, welche Frontend-Option zu deinem Magento- oder Adobe-Commerce-Setup passt? Sprich mit dem Laioutr-Team und wir gehen deine aktuelle Architektur durch, von Luma bis FMP, und zeigen dir, wo das Entkoppeln sinnvoll ist und wo nicht.