Skeleton- & Loading-States: Der Hebel gefühlter SpeedEuer LCP liegt unter zwei Sekunden. Euer IN…
Shopware AXP: Was die Storefront für AI-Käufer rendert
Shopware AXP: Was die Storefront für AI-Käufer rendert
Der Feed bringt das Produkt zum Agent. Wer rendert die Experience?
Diese Frage macht Shopwares Agentic Experience Protocol (AXP) für jedes Frontend-Team im DACH-Shopware-Ökosystem unausweichlich. Mit Release 6.7.10 liefert Shopware einen nativen Agentic-Commerce-Sales-Channel: einen JSONL-Produkt-Feed, der strukturierte Produktdaten direkt an KI-Shopping-Interfaces wie ChatGPT überträgt. Die Feed-Schicht ist jetzt real. Was noch nicht definiert ist: die Render-Schicht.
AXP geht über den Feed hinaus. Es ist eine UCP-Erweiterung, die Rich-Product-Data, Quality-Signals und eingebettete Merchant-Experiences, darunter 3D-Viewer und AR-Vorschauen, neben dem Standard-Produktdatensatz transportiert. Der Feed bringt die Daten zum Agent. Die eingebetteten Experiences, die AXP definiert, müssen trotzdem irgendwo gerendert werden. Dieses Irgendwo ist das Frontend.
Dieser Post ist bewusst keine Wiederholung der Sales-Channel-Mechanik aus unserem früheren Beitrag zum Shopware Agentic Sales Channel. Jener Post behandelte den Feed und den Datenpfad. Dieser Post behandelt, was die Render-Schicht konkret leisten muss, sobald AXP-Rich-Experiences ankommen.
Drei konkrete Frontend-Anforderungen folgen.
Anforderung 1: Progressives Asset-Loading für AXP-Rich-Media, ohne LCP-Einbruch
AXP enthält Referenzen auf hochauflösende 3D-Modelle und AR-Asset-Pakete. Der Feed trägt die Referenz; der Browser muss das Asset laden und rendern. Auf einer Produktdetailseite servieren die meisten Shopware-Storefronts heute einen flachen Bild-Stack, optimiert für LCP. Ein 3D-Viewer oder ein AR-Einstiegspunkt ist ein fundamental anderes Asset-Budget.
Das Problem ist nicht allein die Dateigröße. Es ist das Sequencing. Wenn der Browser das 3D-Asset als render-blockierende Dependency behandelt, bricht der LCP ein. Die Seite gilt als langsam nach Core-Web-Vitals-Messung, bevor der Kunde einen einzigen Pixel Produktinhalt gesehen hat.
Das richtige Pattern ist progressives Asset-Loading mit expliziten Prioritätsstufen:
- Das Standard-Hero-Bild mit LCP-Priorität servieren, genau wie heute.
- Den 3D-Viewer als deferred, nicht-blockierendes Modul einbinden, das nach dem LCP-Event mountet.
- Das AR-Asset-Paket nur bei explizitem User-Intent lazy-laden (Tastendruck, Device-Capability-Check).
Shopwares native Twig-basierte Storefront ist für das flache Bild-PDP-Pattern optimiert. Die Template-Engine rendert serverseitig, was bedeutet: deferred 3D-Modul-Injektion erfordert entweder Client-seitige Hydration-Logik als Aufsatz auf dem Twig-Output oder ein separates JS-Bundle mit eigenem Loading-Lifecycle. Beides ist nicht das Standardverhalten.
Ein Composable-Headless-Frontend entkoppelt die Asset-Loading-Priorität vom Template-System. Der Komponentenbaum entscheidet, was zu welcher Priorität lädt. Einen 3D-Viewer-Component hinzuzufügen, der seinen Asset-Fetch selbst deferrt, ist eine Konfiguration auf Komponentenebene, kein Template-Override. Diese Unterscheidung ist relevant, wenn AXP-Rich-Media-Typen sich mehren: Jeder neue Asset-Typ bekommt seine eigene Loading-Strategie, ohne das Page-Template anzufassen.
Anforderung 2: Ein Component-Resolver für zwei Render-Surfaces
AXP-Quality-Signals und eingebettete Merchant-Experiences sind surface-bewusste Daten, aber sie lösen ihr eigenes Rendering nicht auf. Ein Quality-Signal für eine Materialgüte bedeutet auf einem KI-Agent-Canvas etwas anderes (eine einzeilige strukturierte Textangabe, die ein LLM zitieren kann) als auf einer Brand-Storefront (ein visuelles Badge, ein aufklappbarer Zertifizierungsblock, ein Tooltip). Gleiche Daten, zwei Render-Contracts.
Wenn der Feed und die Storefront dieselbe Produktwahrheit teilen, aber durch separate Templates rendern, gibt es zwei divergente Render-Pfade, die unabhängig gepflegt werden müssen. Jede Schema-Anderung in AXP erzwingt zwei Updates.
Die architektonische Antwort ist ein Component-Resolver: eine einzige Frontend-Schicht, die die AXP-Daten-Payload empfängt und abhängig vom Surface-Kontext den richtigen Render-Component dispatcht.
Hier ein vereinfachtes TypeScript-Beispiel des Resolver-Patterns:
// axp-component-resolver.ts
// Empfängt ein AXP-Payload-Feld und die aktuelle Render-Surface,
// gibt den korrekten React/Vue-Component zurück.
type Surface = 'storefront' | 'agent-canvas';
interface AXPField {
type: 'quality-signal' | 'embedded-experience' | '3d-asset-ref' | 'ar-asset-ref';
value: unknown;
}
const resolvers: Record<AXPField['type'], Record<Surface, React.ComponentType<{ data: unknown }>>> = {
'quality-signal': {
storefront: QualityBadgeComponent, // visuelles Badge + Tooltip
'agent-canvas': QualityTextSnippet, // einfacher strukturierter Text
},
'embedded-experience': {
storefront: EmbeddedExperienceBlock, // volles interaktives Widget
'agent-canvas': ExperienceTextSummary, // Textzusammenfassung + Deep-Link
},
'3d-asset-ref': {
storefront: ThreeDViewerDeferred, // deferred 3D-Mount (siehe Anforderung 1)
'agent-canvas': AssetThumbnailCard, // statisches Thumbnail + Download-Link
},
'ar-asset-ref': {
storefront: ARLaunchButton, // Device-Capability-gesteuerter AR-CTA
'agent-canvas': ARLinkSnippet, // einfacher Link fuer den Agent
},
};
export function resolveAXPComponent(
field: AXPField,
surface: Surface
): React.ComponentType<{ data: unknown }> {
return resolvers[field.type][surface];
}Dieses Pattern hält eine Codebasis als Single-Source-of-Truth für die Render-Logik. Die Storefront-Surface und die Agent-Canvas-Surface teilen Komponentendefinitionen, aber nicht den Render-Output. Wenn Shopware AXP um einen neuen Feldtyp erweitert, kommt ein Resolver-Eintrag dazu. Zwei Template-Systeme müssen nicht gepatcht werden.
Shopwares Twig-Architektur passt nicht auf dieses Pattern, ohne erhebliche Zusatz-Infrastruktur. Twig rendert serverseitige Strings. Surface-bewusster Component-Dispatch ist per Definition eine Client-seitige Aufgabe. Man kann es mit Twig-Blocks und serverseitiger Surface-Detection annähern, aber die Resolver-Logik lebt dann in PHP-Template-Conditionals, nicht in der Komponentenschicht, und kann keinen Client-seitigen Component-State wiederverwenden.
Anforderung 3: Eine Render-Quelle für Feed und Storefront
Das dritte strukturelle Problem ist die Divergenz zwischen dem Sales-Channel-Feed und der Storefront-Darstellung. Beide lesen aus denselben Shopware-Produktdaten, aber über unterschiedliche Output-Pfade: den JSONL-Feed-Generator und den Twig-Template-Renderer. Das ist kein gemeinsamer Code.
Wenn AXP den Produktdatensatz erweitert, muss ein Datenfeld, das dem Feed-Schema hinzugefügt wird, auch im Storefront-Template erscheinen. Heute passieren diese beiden Updates in zwei verschiedenen Systemen: einer Feed-Konfiguration und einem Twig-Snippet. Das Risiko ist stille Divergenz: Der Feed trägt ein Quality-Signal, das die Storefront nicht anzeigt, oder umgekehrt. Ein Kunde, der ein Produkt über einen KI-Agenten entdeckt, sieht reichhaltigere Daten als ein Kunde, der direkt auf der Storefront ankommt.
Die richtige Architektur ist eine einzige Frontend-Schicht, die alles Rendering besitzt: derselbe Komponentenbaum generiert sowohl die Storefront-Ansicht als auch den strukturierten Output, den der Agent-Canvas braucht. Feed und Storefront lesen aus einem Datengraph; die Display-Logik sitzt an einer Stelle.
Für Shopware-Kunden ist das das Kernargument für den Headless-Frontend-for-Shopware-Ansatz: Die Shopware-Store-API wird zur Single-Data-Source. Die Frontend-Schicht, ob Component-Resolver für Agent-Surfaces oder Visual-Editor für Storefront-Pages, liest aus einer API. Es gibt keinen parallelen Template-Pfad zu warten.
Eine Agentic Frontend Management Platform (FMP) erweitert das weiter: Marketer iterieren Storefront-Pages im Studio-Editor ohne Deployment-Zyklus, während dieselbe zugrundeliegende Komponentenbibliothek sowohl die Storefront als auch Agent-Surface-Renderer bedient. Neue AXP-Felder werden zu neuen Komponenten an einer Stelle und rollen dann auf beiden Surfaces aus, ohne einen zweiten Engineering-Durchlauf.
Was Shopwares native Storefront gut macht, und wo die Architekturen divergieren
Shopwares Twig/Symfony-Storefront ist ein robustes, gut gepflegtes CMS-First-Templating-System. Für einen Standard-E-Commerce-Katalog mit flachen Produktdaten ist serverseitiges Rendering aus Twig ein sinnvoller Standard. Das Developer-Ökosystem für Shopware 6 ist gross, und die Plugin-Kompatibilität innerhalb des nativen Stacks ist gut verstanden.
Die architektonische Lucke ist spezifisch: AXP-Rich-Experience-Bursts sind nicht das, wofür Twig gebaut wurde. Ein 3D-Viewer mit deferred Asset-Loading, ein surface-bewusster Component-Resolver und ein einheitlicher Datengraph über Feed und Storefront sind alle client-seitige Kompositionsprobleme. Twig löst server-seitige Templating-Probleme. Die zwei Tooling-Philosophien stehen nicht auf theoretischer Ebene im Konflikt; sie divergieren an dem Punkt, wo AXP-Render-Anforderungen ein Component-First-Modell brauchen.
Das ist keine Aussage, dass die native Storefront falsch ist. Es ist die Beobachtung, dass Performance-Grade-Core-Web-Vitals unter AXP-Rich-Media-Last, surface-bewusstes Rendering und eine einzige Render-Quelle Frontend-Architektur-Entscheidungen erfordern, die ausserhalb des Twig-Modells liegen.
Die Timing-Frage
Shopwares Agentic Commerce Alliance ist live. AXP ist angekündigt, noch nicht vollständig ausgeliefert. Der 6.7.10-Sales-Channel ist heute real; das Embedded-Experience-Protocol wird in Zusammenarbeit mit Alliance-Mitgliedern definiert. Das bedeutet: Der richtige Moment für die Architektur-Entscheidung ist vor dem ersten Fluss AXP-konformer Produktdaten, nicht danach.
Das Frontend-Team, das wartet, bis AXP verpflichtend wird, bevor es seine Render-Architektur prüft, hat dann drei gleichzeitige Probleme: LCP-Regressionen durch nicht optimierte 3D-Asset-Loads, ein divergentes Template-System, das Surfaces nicht auflösen kann, und ein Zwei-Pfad-Wartungsproblem zwischen Feed und Storefront.
Das Team, das die Render-Schicht jetzt prüft, hat ein Fenster, um den Component-Resolver, die progressiven Loading-Stufen und den einheitlichen Datengraph aufzusetzen, bevor das erste AXP-reichhaltige Produkt live geht.
Wenn du durchsprechen möchtest, wie dieses Audit für ein konkretes Shopware-6-Setup aussieht, führen wir gern ein technisches Beratungsgespräch mit deinem Frontend-Team. Keine generischen Slides, nur euer Stack.
Weiterlesen: