Adobe Commerce Frontend 2026: Edge Delivery Services oder Frontend Management Platform - wofür welche Schicht?

Adobe hat im Verlauf von 2024 und 2025 zwei klar unterschiedliche Wege für das Frontend von Adobe Commerce positioniert. Beide laufen unter dem EDS-Dach, aber sie lösen verschiedene Probleme - und sie kommen mit verschiedenen Tradeoffs für Architecture-Teams, die gerade eine Entscheidung treffen müssen.

Dieser Post ist keine Vendor-Kritik und kein "Alternative-zu"-Pitch. Er ist eine Entscheidungsmatrix: Wann reicht Edge Delivery Services als Authoring-Delivery-Stack? Und wann braucht ihr eine Frontend Management Platform (FMP) als separaten Layer?

Was Adobe Edge Delivery Services konkret ist

EDS ist Adobes Hosting-und-Delivery-Infrastruktur, die aus Dokumenten schnell ausgeliefertes HTML macht - serviert von Edge-Nodes nah am Shopper. Das Authoring-Modell ist explizit dokument-basiert: Content-Teams schreiben Seiten in Google Docs, SharePoint/Word oder im DA.live-Interface. Dieser Content wird direkt über GitHub als statische Assets gebaut und an die Edge gepusht.

Für Adobe Commerce spezifisch kommen sogenannte Drop-ins dazu: NPM-Pakete, die Commerce-Kernfunktionen wie Cart, Checkout, Produktdetailseiten und Account-Flows liefern. Der Stack verbindet EDS als CMS/Delivery-Layer mit Adobe Commerce als Backend über diese Drop-in-Komponenten.

Adobes internes Qualitätsziel für EDS-Entwicklung ist "Keeping it 100" - Lighthouse-Score von 100 nach jeder Änderung. In realen Produktions-Migrationen hat man Ausgangswerte von etwa 20 auf konsistente Werte im Bereich 90-100 gesehen.

Das Storefront Builder-Interface (Universal Editor) ergänzt Document Authoring um ein WYSIWYG-Editing-Erlebnis - ähnlich dem Universal Editor, den AEM-Teams kennen.

Was eine Frontend Management Platform leistet

Eine Frontend Management Platform (FMP) ist kein CMS-Ersatz und kein Authoring-Tool - sie ist ein eigenständiger Frontend-Layer zwischen eurem Backend-Stack und dem Delivery-System. Sie trennt die Concerns explizit: Welches Backend liefert Commerce-Daten? Welche Komponenten werden gerendert? Welches Team hat für welchen Part Ownership?

Im Laioutr-Kontext bedeutet das: Composable Frontend läuft auf Next.js 15 oder Nuxt 4, spricht direkt mit der GraphQL- oder REST-API des jeweiligen Backends - Adobe Commerce, aber genauso commercetools, Shopware, OXID oder 50+ weitere. Ein Render-Contract für Komponenten definiert, was eine Komponente bekommt (Daten-Interface) und was sie ausgibt (Markup/UX). Das macht die Schicht austauschbar - sowohl auf Backend-Seite als auch für AI Agents, die dieselbe Komponenten-Library bedienen wie Human-Designer.

Mehr zum Konzept: Was ist eine Frontend Management Platform?

Die Kernfrage: Authoring-Modell oder Render-Contract?

Der fundamentale Unterschied zwischen den beiden Ansätzen liegt nicht in der Performance - beide können exzellente Core-Web-Vitals liefern. Der Unterschied liegt darin, was ihr als zentrale Abstraktion wählt.

EDS: Das Dokument ist die Seite. Content lebt in Google Docs oder SharePoint. Redakteure arbeiten in Tools, die sie kennen. GitHub ist der Deployment-Kanal. EDS baut daraus HTML, das an die Edge ausgeliefert wird. Das ist eine elegante Architektur für Content-heavy Sites mit stabilen Templates und einem primären Backend.

FMP: Die Komponente ist die Einheit. Content lebt im Component-Editor. Architekten definieren, welche Daten eine Komponente bekommt. Backends werden als Data-Sources konfiguriert, nicht als Framework-Annahmen. AI Agents können dieselben Komponenten bedienen wie Marketing-Teams. Das ist eine Architektur für Backend-Flexibilität und Multi-Team-Ownership.

Entscheidungsmatrix: EDS vs. FMP

Kriterium              EDS (Adobe native)           FMP (z.B. Laioutr)
────────────────────── ──────────────────────────── ──────────────────────────────
Authoring-Modell       Dokument-basiert             Component-Editor / Visual
                       (Google Docs / SharePoint)   Builder im Studio
                       + Universal Editor

Backend-Bindung        Adobe Commerce (primär)      Multi-Backend: 50+ Systeme
                       + AEM as Data-Source         inkl. Adobe Commerce, CT,
                                                    Shopware, OXID, Salesforce

Team-Ownership         Content-Team schreibt in     Marketing im Editor,
                       Docs; Dev pflegt Drop-ins     Dev baut Komponenten,
                       und GitHub-Pipeline           klare Responsibility-Split

Komponenten-Modell     Drop-ins (NPM-Pakete von     Eigene Komponenten-Library,
                       Adobe) als Basis             vollständig in eurer Hand

Performance-Baseline   Lighthouse 100 als Ziel      LCP ~1,2s Median (Field),
                       (intern: "Keeping it 100")   Lighthouse-100-ready out-of-box

Agent-Readiness        Drop-in-Architektur gibt      Render-Contract macht
                       wenig expliziten Contract     Komponenten Agent-traversierbar;
                       für AI-Traversal             Larry AI nativ integriert

Multi-Backend-Case     Nicht designed für           Kernarchitektur:
                       Backend-Wechsel /            Backend ist austauschbar
                       Multi-Backend-Setup           ohne Frontend-Rewrite

Vendor-Dependency      Drop-ins sind Adobe-Pakete;  Open-API-Stack; kein
                       GitHub-Deployment in          Abhängigkeit von einzelnem
                       Adobe-Infra-Kanal            Paket-Publisher

Einstiegs-Komplexität  Niedrig für Content-Teams;   Höher initial; deutlich
                       EDS-Boilerplate gut           schneller bei Multi-Backend
                       dokumentiert                  und Team-Split-Anforderungen

Wann EDS die richtige Wahl ist

EDS macht Sinn, wenn diese Bedingungen zutreffen:

• Euer Backend ist Adobe Commerce (und bleibt es absehbar)
• Content-Teams arbeiten bereits mit Microsoft-Office-Tools oder Google Workspace
• Die Redaktions-Workflows sind dokumentzentrisch: Kampagnenseiten, Editorial-Content, Landingpages werden von nicht-technischen Teams in Doc-Form verfasst
• Ihr wollt Adobes Ecosystem vollständig ausschöpfen (AEM + Adobe Commerce + EDS als integrierter Stack)
• Performance-Ziel ist Lighthouse 100 und das Team kann den "Keeping it 100"-Prozess konsequent mitführen

Konkret: Adobe hat gezeigt, dass Migrationen von PWA Studio auf EDS-basierte Storefronts Lighthouse-Scores von unter 25 auf 90+ gebracht haben. Das ist ein realer Beweis für die Performance-These.

Wann eine FMP die bessere Schicht ist

Eine Frontend Management Platform (FMP) ist die klarere Wahl, wenn:

• Ihr aktuell Adobe Commerce nutzt, aber den Backend-Wechsel auf der Roadmap habt (z.B. zu commercetools, Shopware oder Spryker)
• Euer Storefront parallel mehrere Backends ansprechen muss (z.B. Adobe Commerce + separates PIM + CMS)
• Marketing und Development klare getrennte Ownership-Bereiche brauchen (Marketing im Editor ohne Git-Prozess; Dev in der Komponenten-Library)
• AI Agents in euren Frontend-Delivery-Stack integriert werden sollen - mit explizitem Render-Contract statt implizitem Drop-in-Verhalten
• Ihr euer Frontend nicht an den Release-Zyklus eines Paket-Publishers koppeln wollt

Der Artikel Headless Frontend for Adobe Commerce geht tiefer in die Architektur-Varianten für Adobe Commerce als Backend.

Das Lock-in-Argument faktisch bewertet

EDS-Drop-ins sind Adobe-eigene NPM-Pakete. Das bedeutet: Wenn Adobe Breaking-Changes in einem Drop-in einführt, tragt ihr die Upgrade-Last. Der GitHub-Deployment-Kanal ist Teil der Adobe-Infra-Kette. Das ist kein Vorwurf - es ist eine Architektur-Entscheidung mit klaren Tradeoffs.

Eine FMP dagegen separiert den Frontend-Layer vollständig vom Backend. Eure Komponenten-Library ist euer Asset. Das Backend wird als Daten-Source konfiguriert, nicht als Framework-Annahme eingebaut. Mehr zu diesem Architektur-Prinzip auf dem Headless Frontend Hub.

Agentic Commerce: Warum der Render-Contract 2026 wichtiger wird

Der Einzug von AI Agents in Commerce-Workflows - Pricing-Agents, Content-Agents, SEO-Agents - stellt neue Anforderungen an den Frontend-Layer. Ein Agent, der Storefront-Komponenten traversiert und Content-Entscheidungen trifft, braucht ein explizites Interface: Was gibt diese Komponente aus? Welche Daten nimmt sie an? Welche Invarianten gelten?

EDS Drop-ins sind für Human-Content-Authoring designed. Der Render-Contract fehlt als explizites Konzept. Eine FMP mit definierten Komponenten-Interfaces ist strukturell besser auf Agentic Commerce vorbereitet.

Auf der Laioutr Platform-Seite ist der Agentic-Layer inkl. der Frontend Agents (Content Management Agent, SEO Management Agent, Performance Monitoring Agent) dokumentiert.

Fazit: Zwei unterschiedliche Architektur-Philosophien

EDS und eine FMP lösen nicht dasselbe Problem. EDS ist ein Authoring-und-Delivery-System, das für content-getriebene Sites mit Adobe Commerce als primärem Backend optimiert ist. Eine FMP ist ein Frontend-Orchestrations-Layer, der Backend-Unabhängigkeit, explizite Komponenten-Contracts und Multi-Team-Ownership als Architektur-Eigenschaft hat.

Die Entscheidung hängt an drei Fragen:

1. Wie stabil ist eure Backend-Wahl?
2. Wie stark ist euer Authoring-Modell dokumentgetrieben?
3. Wollt ihr in zwei Jahren AI Agents in euren Frontend-Stack integrieren - und wenn ja, über welchen Contract?

Wer Adobe Commerce als Backend behält und primär ein besseres Doc-to-Page-Authoring-System sucht: EDS ist der kürzere Weg. Wer den Frontend-Layer als eigenständige, teamübergreifende Plattform betreibt - mit heutigen oder zukünftigen Backend-Wechseln auf der Agenda - braucht eine FMP.

Ein verwandtes Thema ist der breitere Vergleich zwischen Composable Commerce-Ansätzen, den wir im April 2025 analysiert haben: Adobe Commerce im Kontext von Composable Commerce-Alternativen (als Kontext-Lektüre, nicht als Ersatz für diesen Post).

Weiterführende Links

• Headless Frontend Hub (Pillar 2) - alle Backend-spezifischen Architektur-Guides
• Laioutr Platform - Frontend Management Platform - Komponenten-Layer, Studio, Larry AI und Frontend Agents
• Headless Frontend for Adobe Commerce - Architektur-Varianten im Detail
• Was ist eine Frontend Management Platform? - FMP als Kategorie erklärt (Pillar 1)
• Adobe Commerce im Composable-Context - Markt-Kontext April 2025