AEM Edge Delivery Services Warum Lighthouse 100 im Labor nicht reicht und wie Tags, Einwilligung und Personalisierung in die drei Ladephasen gehören
Edge Delivery Services ist die Auslieferung von Adobe Experience Manager, die mit einem Lighthouse-Wert von 100 beworben wird. Die Architektur ist tatsächlich schlanker als der klassische Weg über Publish-Instanz und Dispatcher. Ob ein Auftritt die Core Web Vitals besteht, entscheidet sich trotzdem in der Produktion: an Tag-Verwaltung, Einwilligungsdialog und Personalisierung, die nach dem Livegang hinzukommen. Diese Seite beschreibt, wo Edge Delivery Services Performance gewinnt und wo sie wieder verloren geht.
Edge Delivery Services im Benchmark: schnellere Antwortzeit, offene Frage beim Hauptinhalt
Im AEM Core Web Vitals Benchmark 2026 sind Auftritte mit Edge Delivery Services im DACH-Raum in 87 Datensätzen je Auftritt und Land erfasst. Davon bestehen 54,0 Prozent die Core Web Vitals auf Mobilgeräten, gegenüber 49,4 Prozent bei der klassischen Auslieferung.
| Kennzahl | Edge Delivery Services | Klassische Auslieferung |
|---|---|---|
| Time to First Byte | 82,4 % | 66,4 % |
| Largest Contentful Paint | 65,5 % | 67,6 % |
| Interaction to Next Paint | 80,3 % | 74,4 % |
| Cumulative Layout Shift | 72,2 % | 75,7 % |
Die Antwortzeit des Servers ist der Teil, den die Auslieferung direkt beeinflusst. Der Largest Contentful Paint hängt zusätzlich an Bildern, Schriften, Einwilligungsdialog und allem, was vor dem Hauptinhalt lädt. Die Gruppe ist klein und nicht zufällig zusammengesetzt: Wer auf Edge Delivery Services wechselt, baut das Frontend neu und trennt sich dabei oft von Altlasten. Im eigenen Abruf bestehen die 51 Auftritte mit Edge Delivery Services zu 45,1 Prozent, die übrigen AEM-Auftritte zu 68,4 Prozent; ein Vorsprung der Auslieferungsart lässt sich daraus nicht ableiten.
Drei Ladephasen in Edge Delivery Services: eager, lazy und delayed
Edge Delivery Services liefert vorgerendertes HTML über ein CDN aus und teilt das Laden einer Seite in drei Phasen. Adobe beschreibt sie unter Keeping it 100:
- Eager: alles, was für den ersten sichtbaren Bereich und das LCP-Element nötig ist. Adobe nennt als Faustregel, vor dem Largest Contentful Paint nur von einem Host und insgesamt weniger als 100 Kilobyte zu laden.
- Lazy: Kopf und Fuß der Seite, Blöcke unterhalb des sichtbaren Bereichs, weitere Styles und Schriften, geladen nach dem Hauptinhalt.
- Delayed: Code außerhalb der Kontrolle des Projekts, vor allem Tags, Analyse und andere Drittanbieter, geladen erst nach dem Hauptinhalt und ohne Einfluss auf den ersten Aufbau: im aktuellen Boilerplate nach einer Einwilligungsprüfung, in vielen bestehenden Projekten mit einer festen Verzögerung von etwa drei Sekunden.
Diese Aufteilung ist der eigentliche Grund für die guten Laborwerte. Sie hält nur, solange jedes neue Skript in der richtigen Phase landet.
Adobe Tags und Martech: die verzögerte Phase entscheidet über die Reaktionszeit
Ein typisches Muster nach einer Migration: Der Einbettungscode der Tag-Verwaltung, etwa Adobe Experience Platform Tags (früher Adobe Launch), wird aus der alten Plattform übernommen und synchron im Kopf eingebunden. Damit lädt vor dem Hauptinhalt wieder ein zweiter Host mit umfangreichem JavaScript, und die Ladephasen sind wirkungslos.
Schwieriger ist Personalisierung, etwa mit Adobe Target. Läuft sie in der verzögerten Phase, sieht der Besucher kurz den Standardinhalt, bevor er ausgetauscht wird. Läuft sie in der ersten Phase, belastet sie den Hauptinhalt. Adobe hat für Edge Delivery Services eigene Ansätze entwickelt, die die Martech-Bausteine auf die Ladephasen verteilen. Welche Variante je Seitentyp gilt, gehört vor dem Livegang entschieden und im Performance-Budget festgehalten. Wie die Ladephase auf die Interaction to Next Paint wirkt, zeigt sich nur in Felddaten.
Einwilligungsdialog bei Edge Delivery Services: oft das LCP-Element auf Mobilgeräten
Auf Mobilgeräten kann der Einwilligungsdialog das größte Element im sichtbaren Bereich sein und wird dann selbst zum LCP-Element. Lädt er in der verzögerten Phase, verschiebt sich in diesem Fall der Largest Contentful Paint auf den Zeitpunkt seines Erscheinens. Lädt er früh als Skript eines Drittanbieters, belastet er die erste Phase.
Wirksam ist ein schlanker Dialog, der mit dem ersten Aufbau erscheint, seinen Platz nicht nachträglich verschiebt und erst die eigentliche Einwilligungslogik verzögert lädt. Die Entscheidung über Anbieter und Darstellung fällt meist im Datenschutz, ihre Wirkung auf die Core Web Vitals gehört in dieselbe Abstimmung.
Operational Telemetry: eigene Felddaten aus Edge Delivery Services
Edge Delivery Services bringt mit Operational Telemetry eine eigene Messung echter Besucher mit. Sie arbeitet mit Stichproben, ohne Cookies und ohne lokale Speicherung, und erfasst Largest Contentful Paint, Interaction to Next Paint und Cumulative Layout Shift. Adobe beschreibt die Daten unter Operational Telemetry.
- Für die Arbeit an der Plattform zeigen die Stichproben Veränderungen je Seite schneller als das gleitende 28-Tage-Fenster des Chrome User Experience Report.
- Für die Bewertung durch Google bleibt der Chrome User Experience Report maßgeblich, wie unter Core Web Vitals messen beschrieben.
- Browser auf iOS liefern erst seit Safari 26.2 (Dezember 2025) Werte für Largest Contentful Paint und Interaction to Next Paint, für Cumulative Layout Shift weiterhin nicht. Der Chrome User Experience Report enthält keine Daten aus Safari. Bei Zielgruppen mit hohem iOS-Anteil gehört das in die Auswertung.
Migration auf Edge Delivery Services: Zielwerte vor dem ersten Block
Edge Delivery Services ersetzt Dispatcher und Client Libraries durch CDN und Blöcke. Die Fragen dahinter bleiben: Cache-Schlüssel und Invalidierung im CDN wie unter AEM Dispatcher Cache beschrieben, Größe und Ladeart des JavaScript wie unter AEM Client Libraries beschrieben. Für die Migration bedeutet das:
- Ausgangswerte je Seitentyp aus Felddaten der bestehenden Plattform, gemessen vor dem Umbau.
- Zielwerte für Largest Contentful Paint, Interaction to Next Paint und Cumulative Layout Shift je Seitentyp, festgelegt vor dem ersten Block.
- Eine Zuordnung jedes Skripts der Tag-Verwaltung zu einer Ladephase, mit Eigentümer und Begründung.
- Abnahme gegen Felddaten nach dem Livegang, nicht gegen den Lighthouse-Wert einer Vorschau.
Die Termine und Wege nach AEM 6.5 stehen unter AEM 6.5 Support-Ende, die Formulierungen für das Lastenheft unter Performance-Anforderungen im AEM-Lastenheft. Alle Ursachen auf AEM-Plattformen ordnet Adobe Experience Manager Performance ein.
Kostenfreie Performance-Erstanalyse buchen
30 Minuten per Video. Sie erhalten die Google-Nutzerdaten Ihrer Plattform im Vergleich zu zwei Wettbewerbern, unabhängig davon, ob wir zusammenarbeiten.
Häufige Fragen zu AEM Edge Delivery Services
Erreicht jeder Auftritt mit Edge Delivery Services gute Core Web Vitals?
Nein. Edge Delivery Services schafft eine gute Ausgangslage, vor allem bei der Antwortzeit des Servers. Ob ein Auftritt die Core Web Vitals besteht, hängt in der Produktion an Tag-Verwaltung, Einwilligungsdialog, Personalisierung und Bildern. Google bewertet die Erfahrung echter Besucher der letzten 28 Tage, nicht den Lighthouse-Wert.
Wohin gehören Adobe Tags (Adobe Launch) bei Edge Delivery Services?
In die verzögerte Phase, die nach dem Hauptinhalt und nach der Einwilligungsprüfung lädt. Ein synchron im Kopf eingebundener Einbettungscode lädt vor dem Hauptinhalt einen zweiten Host und hebt die Ladephasen auf. Für Personalisierung, die früh wirken muss, gehört je Seitentyp entschieden, welcher Teil früher laden darf.
Wie werden die Core Web Vitals bei Edge Delivery Services gemessen?
Mit zwei Quellen. Operational Telemetry erfasst als Stichprobe echte Besucher auf der eigenen Plattform und zeigt Veränderungen je Seite schnell. Der Chrome User Experience Report zeigt, wie Google die Seiten bewertet, und bleibt der Maßstab für die Abnahme.