Headless vs. Klassisch

Klassisch heißt bei Shopify: ein Theme in der Sprache Liquid. Shopify verwaltet Produkte und Bestellungen und erzeugt daraus auch die Seiten, die eure Kunden sehen. Ein System, ein Ort, eine Zuständigkeit.

Headless heißt: Shopify bleibt für Produkte, Lager, Bestellungen und Checkout zuständig, aber die sichtbare Storefront baut ihr selbst, meist mit React. Shopifys eigenes Werkzeug dafür heißt Hydrogen, das passende Hosting Oxygen. Die Verbindung läuft über die Storefront-Schnittstelle.

Wichtig, weil es oft falsch verstanden wird: Der Checkout bleibt in beiden Fällen bei Shopify. Ihr baut die Storefront neu, nicht den Bezahlvorgang. Das ist eine gute Nachricht, denn der Checkout ist der Teil, den ihr am wenigsten selbst bauen wollt.

Der eigentliche Unterschied ist nicht technischer Natur, sondern organisatorischer: bei klassisch gehört die Storefront Shopify, bei Headless gehört sie euch. Mit allem, was Besitz bedeutet, in beide Richtungen.

Das meistgenannte Argument für Headless ist Geschwindigkeit, und es stimmt: eine gut gebaute Hydrogen-Storefront ist schneller als ein durchschnittliches Liquid-Theme. Sie lädt weniger Ballast, rendert gezielter und lässt sich feiner steuern.

Nur wird hier meist das Falsche verglichen. Der Gegner ist selten ein sauber gebautes Liquid-Theme. Der Gegner ist ein gekauftes Theme mit sechs Erweiterungen, drei Schriftfamilien, unkomprimierten Bildern und einem Bewertungs-Skript, das alles blockiert. Gegen dieses Feld gewinnt Headless mühelos, und gegen dieses Feld gewinnt auch ein aufgeräumtes Liquid-Theme.

Was wir in Projekten messen: Der Abstand zwischen einem handgebauten, disziplinierten Liquid-Theme und einer Hydrogen-Storefront ist real, aber deutlich kleiner als der Abstand zwischen einem aufgeräumten und einem überladenen Theme. Die erste Optimierung bringt in fast jedem Shop mehr als der Architekturwechsel, und sie kostet einen Bruchteil.

Deshalb unsere Reihenfolge: Erst das bestehende Theme entrümpeln, Bilder und Schriften in Ordnung bringen, unnötige Apps entfernen. Wenn die Ladezeit danach immer noch euer Engpass ist, reden wir über Headless. In den meisten Fällen ist sie es dann nicht mehr.

Beim Aufbau liegt der Faktor bei zwei bis drei. Ein handgebautes Liquid-Theme bewegt sich je nach Umfang zwischen 15.000 und 40.000 Euro. Eine Hydrogen-Storefront mit vergleichbarem Funktionsumfang liegt zwischen 45.000 und 120.000 Euro. Der Grund ist einfach: Was im Theme mitgeliefert wird, muss bei Headless gebaut werden. Filter, Sortierung, Varianten-Auswahl, Warenkorb, Kundenkonto, Suche, Wunschliste.

Im Betrieb ist der Unterschied dauerhaft. Eine Hydrogen-Storefront ist eine Anwendung mit Abhängigkeiten, die aktualisiert werden wollen. Neue Shopify-Funktionen erscheinen bei klassischen Themes automatisch, bei Headless müssen sie eingebaut werden. Rechnet mit 500 bis 1.500 Euro im Monat allein für Pflege, unabhängig davon, ob ihr etwas Neues wollt.

Und dann der Posten, der in keiner Kalkulation steht: Apps. Der Shopify App Store ist auf Themes ausgelegt. Bewertungen, Treueprogramme, Zusatzverkäufe, Abo-Modelle: bei klassisch installiert, konfiguriert, fertig. Bei Headless funktioniert nur der Teil, der eine offene Schnittstelle bietet, und die sichtbare Seite baut ihr nach. Jede App wird damit vom Klick zum kleinen Projekt.

Das ist der Punkt, der in Headless-Projekten am häufigsten unterschätzt wird, und der Grund, warum manche Shops zwei Jahre später bei uns landen und zurück wollen.

Das ist die Frage, die über die Zufriedenheit im zweiten Jahr entscheidet, und sie wird vor dem Projekt fast nie gestellt.

Bei klassischen Themes arbeitet euer Marketing im Editor. Abschnitte verschieben, Bilder tauschen, eine Landingpage für die Kampagne bauen, den Banner zum Feiertag ändern. Ohne Entwickler, ohne Ticket, ohne Wartezeit. Das ist der stärkste und am meisten unterschätzte Vorteil der klassischen Bauweise.

Bei Headless gilt: Änderbar ist, was jemand als änderbar gebaut hat. Wenn die Startseite als feste Struktur programmiert wurde, braucht jede Anpassung einen Entwickler. Gute Headless-Projekte lösen das, indem sie ein eigenes Redaktionssystem anbinden und dort pflegbare Bausteine definieren. Das funktioniert gut, kostet aber zusätzlich Aufbau und ist selbst wieder ein System, das gepflegt werden will.

Die Frage, die wir im Erstgespräch stellen: Wer ändert bei euch die Startseite, wenn nächste Woche eine Kampagne startet? Kommt eine Person aus dem Marketing, ist klassisch fast immer richtig. Kommt „unser Entwickler", ist Headless überhaupt erst eine Option.

Wir raten selten zu Headless, aber es gibt klar umrissene Situationen, in denen es die richtige Antwort ist.

Erstens: die Storefront ist eher Anwendung als Katalog. Ein Konfigurator mit vielen Abhängigkeiten, ein Rechner, eine Auswahlstrecke über mehrere Schritte, eine Visualisierung in Echtzeit. Sobald der Kern eures Verkaufs eine Oberfläche ist, die Liquid nicht abbilden kann, ist Headless kein Luxus, sondern die Voraussetzung.

Zweitens: eine Oberfläche, mehrere Ausgaben. Wenn dieselbe Storefront mehrere Marken, mehrere Länder mit unterschiedlichen Sortimenten oder zusätzlich eine App bedienen soll, spart Headless echte Doppelarbeit. Ihr baut die Logik einmal und gebt sie mehrfach aus.

Drittens: Inhalte führen, nicht Produkte. Wenn ein professionelles Redaktionssystem euer Zentrum ist und der Shop einer von mehreren Kanälen, passt Headless zur Realität. Der Shop wird zum Bestandteil einer größeren Seite statt umgekehrt.

Viertens: Ladezeit ist nachweislich der Engpass. Betonung auf nachweislich. Wenn ihr gemessen habt, dass mobile Besucher abspringen, wenn ihr das Theme bereits optimiert habt und die Werte immer noch nicht reichen, dann ist der Architekturwechsel der nächste sinnvolle Schritt. Vorher nicht.

Die gute Nachricht zuerst: Der Rückweg ist deutlich einfacher als bei einem Plattformwechsel. Produkte, Kunden, Bestellungen und der Checkout liegen ohnehin bei Shopify. Ihr wechselt nur die Storefront zurück auf ein Theme.

Was ihr verliert, ist die Investition in die Hydrogen-Storefront und alles, was daran gebaut wurde. Was ihr behaltet, ist der komplette Handel. Das ist ein wesentlich milderer Ausgang als bei einem echten Systemwechsel, und es ist ein Argument dafür, Headless auszuprobieren, wenn ihr unsicher seid, aber die Mittel habt.

Wann wir den Rückweg begleitet haben: meist zwei bis drei Jahre nach dem Aufbau, wenn der ursprüngliche Entwickler nicht mehr an Bord war und niemand die Storefront weiterentwickeln konnte. Nicht die Technik war das Problem, sondern die Abhängigkeit von wenigen Köpfen. Das ist das eigentliche Risiko von Headless, und es steht in keinem Angebot.

Unsere Empfehlung, wenn ihr Headless baut: Setzt auf Hydrogen statt auf einen selbstgewählten Aufbau, dokumentiert sauber, und stellt sicher, dass mehr als eine Person das System versteht. Dann ist Headless eine Architektur. Sonst ist es ein Personenrisiko.