Wann Headless bei Adobe Commerce sinnvoll ist

Die meisten Händler, die mich nach Headless fragen, wollen wissen, warum ihr Shop langsam ist und warum jede Änderung im Frontend drei Wochen dauert. Headless kann beides beheben, ein gut gebautes Theme allerdings 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 Umsatz einen Headless-Storefront auf Basis von ScandiPWA im Produktivbetrieb betreut und arbeite außerdem mit Hyvä und PWA Studio. Beide Ansätze funktionieren, aber keiner ist für jeden die richtige Standardwahl.

Was Headless bei Adobe Commerce bedeutet

In einem klassischen Setup rendert Adobe Commerce jede Seite in PHP aus Layout-XML, Blöcken und 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.

Für diese separate Anwendung gibt es vier Wege:

• 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 Lizenzierung, denn 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. Bei allen haben Sie statt einer Anwendung zwei, die gebaut, deployt, überwacht und aktualisiert werden müssen.

Was Hyvä verändert hat

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

Hyvä hat diesem Argument größtenteils den Boden entzogen. Es ersetzt das Luma-Frontend durch Alpine.js und Tailwind CSS und behält das serverseitige Rendering in Magento. Die Seiten werden leichter, und die Frontend-Arbeit geht schneller. Backend-Funktionen, Extensions und Admin-Einstellungen funktionieren 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 Vergleich, der sich heute lohnt, ist also 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. Der Storefront ist stark interaktiv. Produktkonfiguratoren, viel clientseitige Interaktion oder personalisierte Inhalte lassen sich mit einem serverseitig gerenderten Theme nur mühsam umsetzen.
4. Sie haben ein Frontend-Team. Eigene JavaScript-Entwickler, die den Storefront langfristig verantworten. Eine Agentur, die ihn beim Launch übergibt, zählt nicht.
5. Das Budget reicht für zwei Anwendungen. Neben den Entwicklungskosten fallen jedes Jahr die laufenden Kosten für zwei Codebasen an, jede mit eigener Deployment-Pipeline und eigenem Monitoring.

Punkt 4 wiegt am schwersten. Ein Headless-Storefront ohne Team, das ihn verantwortet, altert schlecht. Framework-Updates bleiben liegen, und Frontend und GraphQL-Schema passen irgendwann nicht mehr zusammen. Am Ende steht der Shop auf alten Versionen, weil sich niemand das Upgrade leisten kann.

Wann nicht

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

• Sie von vielen Frontend-Extensions abhängen. Jedes Drittanbieter-Modul, das das Frontend berührt, braucht ein Headless-Gegenstück. Zahlungsarten, Bewertungen, Kundenbindung, B2B-Schnellbestellung: Jedes davon ist ein kleines Integrationsprojekt, und manche Anbieter haben gar keine GraphQL-Abdeckung.
• Ihr Team PHP-zentriert ist. Hyvä hält Magento-Entwickler 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“, erreichen Sie das mit Hyvä und der Backend-Arbeit aus meiner Performance-Checkliste für einen Bruchteil der Kosten.
• Ihr Merchandising-Team auf den Admin angewiesen ist. Page Builder, Widgets, CMS-Blöcke und Layout-Updates funktionieren mit einem Magento-Theme nativ. In einem Headless-Storefront muss jedes davon eigens angebunden oder ersetzt werden.

Die Kosten, die unterschätzt werden

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.

Der erste ist die GraphQL-Performance. Der Full-Page-Cache schützt GraphQL nicht so, wie er einen Shop mit Theme schützt. Ungecachte GraphQL-Abfragen, die verschachtelte Produktdaten anfordern, laufen jedes Mal durch PHP. Query-Design, Caching am Edge und Resolver-Profiling gehören ab dem ersten Sprint zum Projekt.

Danach kommt der 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.

Der dritte Punkt ist, das bestehende SEO-Niveau zu halten. URL-Rewrites, Canonical-Tags, strukturierte Daten, hreflang und Weiterleitungen hat bisher Magento erzeugt. 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 der Entwickler, beginnen Sie mit Hyvä und hören hier auf.
2. Wer verantwortet den Storefront in drei Jahren? Ohne festes 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ä liefert Katalog und Checkout aus. Eine separate Anwendung, die dieselben Commerce-APIs aufruft, übernimmt nur den Teil der Website, der sie braucht, etwa einen Konfigurator oder einen Content-Hub.

Was ich tun würde

Für die meisten mittelgroßen Adobe-Commerce-Shops empfehle ich 2026 Hyvä plus die Backend-Korrekturen aus meiner Performance-Checkliste. 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. Wenn das zutrifft, ist es mir lieber, Sie setzen Headless richtig um statt halbherzig.

Wenn Sie diese Entscheidung gerade abwägen, beginnt meine Leistung Storefront-Strategie mit einer zweiwöchigen Analyse. Darin beantworte ich die vier Fragen für Ihren Shop schriftlich.