Shopify Theme oder Headless-Storefront?

Eine betriebswirtschaftliche Frage im technischen Gewand

Fast jedes Headless-Projekt, das uns zur Prüfung vorlag, startete aus einem von zwei Gründen: Die Seite fühlte sich langsam an, oder das Team fühlte sich vom Theme eingeschränkt. Beides sind echte Probleme, und keines wird durch das Entkoppeln des Frontends automatisch gelöst. Eine langsame Seite ist meist wegen Skripten und Bildern langsam. Ein einschränkendes Theme schränkt meist ein, weil es ohne Content-Modell gebaut wurde.

Die Fragen, die das Ergebnis wirklich bestimmen, sind unspektakulärer: Wie oft müssen Nicht-Entwickler Seiten ändern, wie viele Menschen können ein eigenes Frontend warten, und wer ist zuständig, wenn im Weihnachtsgeschäft eine Abhängigkeit aktualisiert werden muss.

Was ein modernes Theme heute abdeckt

Der Abstand zwischen Themes und eigenen Frontends ist deutlich kleiner geworden. Sections und Blöcke lassen sich auf jedem Template anordnen, App-Blöcke platzieren Funktionen aus Drittanbieter-Apps ohne Codeeingriff, und strukturierte Inhalte lassen sich mit Metafeldern und Metaobjekten modellieren, statt sie in ein Rich-Text-Feld zu kleben.

Internationalisierung, mehrere Währungen und marktspezifische Inhalte übernimmt die Plattform. Der Checkout ist an definierten Stellen erweiterbar. Das Ergebnis: Die Redaktion arbeitet ohne Deployment, und die meisten Anforderungen werden zur Konfiguration statt zur Entwicklung.

Wann Headless sich tatsächlich rechnet

Es gibt klare Fälle, und sie haben eines gemeinsam: Die Storefront ist nicht das Einzige, was gebaut wird.

• Editorial Commerce mit echtem CMS-Workflow. Magazinformate, lange Inhalte, komplexe Freigaberegeln und eine Redaktion, die ohnehin in einem eigenen System arbeitet.
• Mehrere Marken oder Märkte auf einer Codebasis. Wenn sich die Nutzerführung je Marke stark unterscheidet, die Logik aber geteilt bleiben soll, kann ein eigenes Frontend günstiger sein als fünf auseinanderlaufende Themes.
• Interaktionen, die die Plattform nicht abbildet. Konfiguratoren, Angebotsstrecken, portalartige B2B-Bereiche oder tiefe Integrationen in eine bestehende Systemlandschaft.
• Ein vorhandenes Frontend-Team. Kein Freelancer für den Launch, sondern ein Team, das auch für Wartung, Updates und den nächsten Relaunch noch da ist.

Die Kosten, die selten in der Planung stehen

Das App-Ökosystem hört auf, per Klick zu funktionieren. Jede App, die auf der Storefront etwas darstellt, braucht eine eigene Umsetzung, und App-Updates werden zu Entwicklungstickets. Geplant ist das beherrschbar, nach dem Launch entdeckt ist es teuer.

Der Redaktionsprozess muss ersetzt werden. Alles, was der Theme-Editor konnte — Sections anordnen, ein Kampagnenbanner terminieren, ein Hero-Bild tauschen — braucht ein Gegenstück im CMS, sonst wird daraus eine Entwickleranfrage.

Dazu kommt die Dauerlast: Hosting, Build-Pipeline, Monitoring, Abhängigkeiten aktualisieren — und die Tatsache, dass sich Wissen auf sehr wenige Köpfe konzentriert. Fragen Sie früh, wer das in zwei Jahren betreibt und was passiert, wenn diese Person geht.

Performance ist eine Disziplin, keine Architektur

Ein eigenes Frontend mit fünf Marketing-Tags, drei Chat-Widgets und unoptimierten Hero-Bildern ist langsamer als ein diszipliniertes Theme. Die Hebel, die die Core Web Vitals wirklich bewegen, sind in beiden Welten dieselben: wie viele Drittanbieter-Skripte laden, wie Bilder ausgeliefert werden, wie Schriften eingebunden sind und wie viel Arbeit vor dem ersten Bildaufbau passiert.

Unsere eigenen Seiten bauen wir als statische Seiten mit eingebettetem kritischem CSS und ohne Client-Framework, weil das der günstigste Weg zu Spitzenwerten ist. Der Punkt ist nicht der Stack — der Punkt ist, dass jedes zusätzliche Skript sich rechtfertigen muss.

Der schnellste Shop ist nicht der mit der modernsten Architektur, sondern der mit den wenigsten Skripten.

Fünf Fragen, die die Entscheidung tragen

Beantworten Sie diese ehrlich, bevor Technologien verglichen werden:

• Wie oft ändern Nicht-Entwickler Seiten? Wöchentliche Kampagnenänderungen ohne Deployment sprechen für das Theme; ein quartalsweiser Release-Zyklus tut das nicht.
• Wer wartet das Frontend in zwei Jahren? Ein benanntes Team, kein Vorhaben. Eigene Frontends scheitern leise, wenn die Person geht, die sie gebaut hat.
• Welche Apps sind geschäftskritisch? Listen Sie sie auf und prüfen Sie, was jede einzelne im Nachbau kostet. Diese Liste ist oft schon die ganze Antwort.
• Was ist im Theme wirklich unmöglich? Konkret aufschreiben. „Mehr Freiheit“ ist keine Anforderung; ein Konfigurator mit 200 Varianten ist eine.
• Wie hoch ist das Budget nach dem Launch? Eine eigene Storefront braucht jedes Jahr ein Wartungsbudget, nicht nur einmalig ein Projektbudget.

Der Mittelweg, der gern übersehen wird

Es ist keine Entweder-oder-Frage. Ein Theme lässt sich mit eigenen App-Blöcken und einer privaten App genau dort erweitern, wo es wirklich speziell wird, während alles Standardisierte auf der Plattform bleibt. Eine einzelne Strecke — ein Konfigurator, ein Landing-Bereich, ein B2B-Portal — kann als eigene Anwendung neben dem Shop laufen.

Dieser Weg erhält den Redaktionsprozess, erhält das App-Ökosystem und setzt das Entwicklungsbudget dort ein, wo es einen Unterschied macht. In den meisten Projekten ist es zugleich die Entscheidung, die sich später noch revidieren lässt — und das ist mehr wert, als es klingt.