Headless oder klassische Storefront? Eine ehrliche Entscheidung
Headless Commerce wird oft als nächster Schritt verkauft. Für manche Shops ist er das, für viele ist er ein zweites Softwareprojekt, das niemand braucht. Woran Sie den Unterschied erkennen — mit unseren eigenen Messungen an der Shopware Store API und an 51 Shopware-Startseiten.
„Wir wollen headless" ist in Shop-Projekten inzwischen ein häufiger Satz. Dahinter stehen meist gute Gründe: Geschwindigkeit, Freiheit bei der Gestaltung, mehrere Kanäle aus einem System. Ob Headless diese Gründe einlöst, hängt aber weniger an der Technik als an der Organisation, die den Shop danach betreibt.
Dieser Beitrag ist keine Werbung für eine Architektur. Er beschreibt, was sich ändert, wenn ein Shopware-Shop sein eigenes Frontend bekommt, und wann die klassische Storefront die ehrlichere Antwort ist.
Was Headless wirklich bedeutet
In der klassischen Storefront erzeugt Shopware die Seiten selbst: Kategorie, Produkt, Warenkorb, Checkout, dazu alles, was Suchmaschinen sehen. Headless heißt, dass Shopware nur noch Daten liefert und ein eigenes Frontend daraus die Seiten baut.
Das klingt nach einem Austausch der Oberfläche. Tatsächlich entsteht ein zweites System: mit eigenem Code, eigenen Updates, eigenem Hosting und eigenen Fehlern. Die Frage ist also nicht „können wir das bauen?", sondern „wollen wir dauerhaft zwei Systeme betreiben?".
Was die Schnittstelle hergibt
Die technische Sorge, die Store API könne nicht genug, ist meist unbegründet. Wir haben in Shopware 6.7.13.1 zwanzig vorab festgelegte Storefront-Funktionen gegen die Store API geprüft — von Listing und Suche über Warenkorb bis Registrierung. Alle zwanzig waren erreichbar (zur Messung). Die einzige praktisch relevante Lücke war der Formularschutz: Für das Captcha gibt es keine Store-API-Route.
Die Schnittstelle ist also selten das Problem. Das Problem ist alles, was die Storefront heute nebenbei erledigt.
Was die Storefront nebenbei erledigt
| Aufgabe | klassische Storefront | Headless |
|---|---|---|
| Seiten erzeugen | Shopware | eigenes Frontend |
| Canonicals, Sitemap, strukturierte Daten | ab Werk | selbst bauen |
| Plugins mit Oberfläche | laufen mit | Oberfläche fehlt, oft auch die Schnittstelle |
| Updates | ein System | zwei Systeme, zwei Zyklen |
| Fehlerseiten, Weiterleitungen | ab Werk | selbst bauen |
| Team-Wissen | Twig, Theme, Shopware | Frontend-Framework, Hosting, Shopware |
Jede Zeile auf der rechten Seite ist kein Hindernis, aber Arbeit — vor dem Start und danach in jedem Monat, in dem der Shop läuft.
Der Geschwindigkeits-Irrtum
Der häufigste Grund für Headless ist die Ladezeit. Unsere Labormessung an 51 Shopware-Startseiten zeigt, wo sie verloren geht: Die Server antworteten im Median nach 0,12 Sekunden, das größte Element der Seite erschien im gedrosselten Mobil-Labor aber erst nach 9,6 Sekunden. Gebremst haben Bilder, Slider und Banner (zur Messung).
Das Ergebnis stammt aus dem Labor, nicht von echten Besuchern, und gilt nur für Startseiten. Es zeigt aber eine Richtung: Ein neues Frontend mit denselben schweren Bildern und Slidern wird nicht schneller. Wer schneller werden will, sollte zuerst die Storefront entlasten — das ist billiger und schneller messbar.
Wann Headless die richtige Wahl ist
Es gibt gute Gründe, und sie haben eines gemeinsam: Sie verlangen etwas, das die Storefront nicht kann.
- Mehrere Kanäle aus denselben Daten. App, Terminal im Laden, Kundenportal, Website — alle aus einem Katalog.
- Inhalte und Einkauf verschmelzen. Eine Markenwelt, in der Redaktion und Produkte auf eine Weise zusammenlaufen, die Erlebniswelten nicht abbilden.
- Ein vorhandenes Frontend-Team. Wer bereits mit einem JavaScript-Framework arbeitet und den Shop selbst gestalten will, gewinnt Freiheit, die er auch nutzen kann.
Wann die klassische Storefront besser ist
- Der Shop soll vor allem schneller werden.
- Viele Plugins mit eigener Oberfläche sind im Einsatz.
- Niemand im Team kann ein zweites System dauerhaft pflegen.
- Das Budget reicht für den Bau, aber nicht für den Betrieb danach.
Wie die Shopware-PWA nach dem Stand von 2025 aufgebaut war, beschreibt unser Beitrag Die Shopware 6 PWA im Detail. Für die Entscheidung heute zählt weniger das Produkt als die Frage, wer das Frontend nach dem Start betreut.
Headless lohnt sich, wenn es etwas ermöglicht, das die Storefront nicht kann — und wenn jemand das zweite System dauerhaft betreibt. Für Geschwindigkeit allein ist es selten die Antwort.
Wenn Sie vor dieser Entscheidung stehen, klären wir sie in einem Architektur-Workshop — mit der Prüfung Ihrer Plugins und der Liste, was ein eigenes Frontend selbst leisten müsste. Mehr dazu auf der Seite Headless Commerce mit Shopware.
