Wann Headless bei Adobe Commerce sinnvoll ist

Die meisten Händler, die mich nach Headless fragen, stellen eigentlich eine andere Frage: Warum ist mein Shop langsam, und warum dauert jede Änderung im Frontend drei Wochen? Headless kann beides beantworten. Ein gut gebautes Theme auch. Der Unterschied liegt in den Kosten und darin, wer sie in den nächsten fünf Jahren trägt.

Ich habe für einen Händler mit achtstelligem GMV einen Headless-Storefront mit ScandiPWA im Produktivbetrieb betreut, und ich arbeite mit Hyvä und PWA Studio. Beides funktioniert. Keines davon ist für alle die richtige Standardlösung.

Was Headless bei Adobe Commerce bedeutet

In einem klassischen Setup rendert Adobe Commerce jede Seite in PHP: Layout-XML, Blöcke, Templates. In einem Headless-Setup ist Adobe Commerce nur noch das Backend. Eine separate Anwendung rendert den Storefront und spricht über GraphQL oder REST mit Commerce.

Diese separate Anwendung kann sein:

• PWA Studio: Adobes React-Toolkit für einen Storefront auf Basis der Commerce-GraphQL-API.
• ScandiPWA: ein React-Storefront, gepflegt von einer Magento-Agentur, ebenfalls auf GraphQL.
• Adobes Storefront auf Edge Delivery Services: Commerce-Blöcke und Drop-in-Komponenten, die Adobe inzwischen für neue Storefronts empfiehlt. Prüfen Sie zuerst die Lizenz: Die Drop-ins brauchen eine Commerce-Lizenz, die sie abdeckt.
• Ein eigenes Frontend in Next.js, Nuxt oder Ähnlichem, von Ihrem Team auf Basis derselben APIs entwickelt.

Alle verlagern das Rendering aus Magento heraus. Alle hinterlassen Ihnen zwei Anwendungen, die gebaut, deployt, überwacht und aktualisiert werden müssen, statt einer.

Was Hyvä verändert hat

Jahrelang war das eigentliche Argument für Headless, dass Luma, das Standard-Theme, langsam ist und mühsam in der Entwicklung. RequireJS, Knockout und viel JavaScript auf jeder Seite. Headless war der Ausweg.

Hyvä hat den größten Teil dieses Arguments erledigt. Es ersetzt das Luma-Frontend durch Alpine.js und Tailwind CSS und behält das serverseitige Rendering in Magento. Die Seiten werden leicht, die Frontend-Arbeit wird schnell, und jede Backend-Funktion, jede Extension und jede Admin-Einstellung funktioniert weiter so, wie das Unternehmen sie kennt. Seit November 2025 ist das Hyvä Theme selbst kostenlos und Open Source unter OSL 3.0 und AFL 3.0; Hyvä Checkout und die Enterprise-Produkte bleiben kommerziell.

Der ehrliche Vergleich lautet heute also nicht „Headless gegen langsames Luma“. Er lautet „Headless gegen Hyvä“.

Wann sich Headless lohnt

Ich empfehle einen separaten Storefront, wenn mindestens zwei dieser Punkte zutreffen:

1. Commerce ist eines von mehreren Backends. Der Storefront liest auch aus einem CMS, einem PIM, einer Buchungs-Engine oder einer Content-Plattform, und Magento sollte nicht der Ort sein, an dem alles zusammenläuft.
2. Sie brauchen mehr als ein Frontend. Ein Webshop plus native App, Kiosk-Terminals oder ein Marktplatz-Kanal, die alle dieselben Warenkorb- und Katalog-APIs nutzen.
3. Das Erlebnis ist das Produkt. Viel Interaktivität, Konfiguratoren, personalisierte Inhalte, gegen die ein serverseitig gerendertes Theme ankämpfen müsste.
4. Sie haben ein Frontend-Team. Eigene JavaScript-Entwickler, die den Storefront langfristig verantworten, keine Agentur, die ihn beim Launch übergibt.
5. Das Budget reicht für zwei Anwendungen. Die Baukosten und auch die laufenden Kosten für zwei Codebasen, zwei Deployment-Pipelines und zwei Monitoring-Setups, jedes Jahr.

Punkt 4 wiegt am schwersten. Ein Headless-Storefront ohne verantwortliches Team altert schlecht. Framework-Updates stauen sich, das GraphQL-Schema driftet, und der Shop bleibt auf alten Versionen stehen, weil sich niemand das Upgrade leisten kann.

Wann nicht

Bleiben Sie bei einem serverseitig gerenderten Theme, in der Praxis Hyvä, wenn:

• Ihre Extensions Ihr Geschäft sind. Jedes Drittanbieter-Modul, das das Frontend berührt, braucht ein Headless-Gegenstück. Zahlungsarten, Bewertungen, Kundenbindung, B2B-Schnellbestellung: Jedes ist ein kleines Integrationsprojekt, und manche Anbieter haben gar keine GraphQL-Abdeckung.
• Ihr Team PHP-zentriert ist. Ihre Entwickler kennen Magento. Hyvä hält sie produktiv. Ein React-Storefront macht sie abhängig von dem, der das JavaScript schreibt.
• Es Ihnen um Geschwindigkeit geht. Lautet der Auftrag „schnellere Seiten und bessere Core Web Vitals“, bringen Sie Hyvä plus die Backend-Arbeit aus meiner Performance-Checkliste für einen Bruchteil der Kosten ans Ziel.
• Ihr Merchandising-Team im Admin arbeitet. Page Builder, Widgets, CMS-Blöcke und Layout-Updates funktionieren mit einem Magento-Theme nativ. In einem Headless-Storefront braucht jedes davon expliziten Support oder einen Ersatz.

Die unterschätzten Kosten

Bereich	Hyvä-Theme	Headless-Storefront
Zu betreibende Anwendungen	Eine	Zwei, plus API-Caching
Drittanbieter-Module	Hyvä-Kompatibilitätsmodul, oft verfügbar	Pro Modul neu gebaut oder integriert
Content-Werkzeuge im Admin	Nativ	Teilweise, Aufwand pro Funktion
Upgrades	Magento-Upgrade	Magento-Upgrade plus Frontend-Framework-Upgrade
Nötige Kompetenzen	Magento, Tailwind, Alpine.js	Magento, GraphQL, React o. Ä., Node-Hosting

Drei Punkte überraschen Teams am häufigsten.

GraphQL-Performance. Der Full-Page-Cache schützt Sie nicht so wie bei einem Shop mit Theme. Ungecachte GraphQL-Abfragen mit tiefen Produktdaten treffen bei jeder Anfrage PHP. Sie brauchen Query-Design, Caching am Edge und Resolver-Profiling ab dem ersten Tag.

Checkout. Er ist der am stärksten angepasste Teil jedes Shops und der teuerste beim Neubau. Zahlungsanbieter, Steuern, Versandregeln und Betrugsprüfungen müssen alle über die API funktionieren.

SEO-Parität. URL-Rewrites, Canonical-Tags, strukturierte Daten, hreflang und Weiterleitungen lagen in Magento. Bei Headless muss der Storefront jedes davon nachbauen, sonst bricht der Traffic nach dem Launch ein.

Eine Entscheidung in vier Fragen

Wenn mich ein Händler fragt, ob er auf Headless umsteigen soll, stelle ich diese Fragen, in dieser Reihenfolge:

1. Welches Problem lösen Sie? Lautet die Antwort Geschwindigkeit oder Produktivität des Teams, beginnen Sie mit Hyvä und hören hier auf.
2. Wer verantwortet den Storefront in drei Jahren? Kein benanntes Team, kein Headless.
3. Wie viele Extensions mit Frontend-Anteil nutzen Sie? Listen Sie sie auf. Prüfen Sie für jede den API-Support. Diese Liste beendet die Diskussion oft.
4. Gibt es einen Kanal oder eine Datenquelle, die Magento nicht rendern sollte? Wenn ja, beginnt sich Headless zu rechnen.

Ein nützlicher Mittelweg ist ein Hybrid: Hyvä für Katalog und Checkout und eine separate Anwendung nur für den Teil der Website, der sie braucht, etwa einen Konfigurator oder einen Content-Hub, der dieselben Commerce-APIs aufruft.

Was ich tun würde

Für die meisten mittelgroßen Adobe-Commerce-Shops empfehle ich 2026 Hyvä mit solider Backend-Performance-Arbeit. Das liefert den Großteil der Geschwindigkeit von Headless bei deutlich geringeren Langzeitkosten. Headless empfehle ich Händlern mit mehreren Kanälen, mehreren Datenquellen und einem Frontend-Team, das bleibt. Dann sollte es richtig gebaut werden, nicht halb.

Wenn Sie diese Entscheidung gerade abwägen: Die Leistung Headless-Storefronts beginnt mit einer zweiwöchigen Analyse, die die vier Fragen oben für Ihren Shop schriftlich beantwortet.