CDN für Enterprise-Plattformen Was ein Content Delivery Network vor AEM und Magnolia für die Antwortzeit leistet und wo seine Wirkung endet

Von Christian Schreiber, Web Performance Consultant für AEM und Magnolia, aktualisiert am 10. November 2026

Ein Content Delivery Network liefert Seiten und Dateien aus Knoten in der Nähe der Besucher aus und entlastet die Publish- oder Public-Instanzen dahinter. Ob das die Time to First Byte tatsächlich senkt, entscheidet die Konfiguration: Nur eine Anfrage, die das CDN aus dem Speicher beantwortet, ist schnell. Jede andere läuft bis zur Plattform durch und trägt deren Antwortzeit plus den Umweg.

Wie groß der Hebel ist, zeigt der Core Web Vitals Benchmark 2026. Auf Smartphones halten 68,7 Prozent der geprüften AEM-Auftritte und 57,4 Prozent der Magnolia-Auftritte die Antwortzeit im guten Bereich bis 800 Millisekunden. Bei den Auftritten, deren Hauptinhalt zu langsam lädt, liegt die Ursache bei 80,3 Prozent (AEM) und 78,8 Prozent (Magnolia) bereits in der Antwortzeit, im Median 1.565 und 1.668 Millisekunden.

CDN je Plattform: Fastly bei AEM Cloud Service, Edge Delivery Services und Magnolia DX Cloud

Welches CDN vor einer Plattform steht, ist bei den Cloud-Angeboten der Hersteller festgelegt. Bei selbst betriebenen Plattformen wählt der Betreiber.

CDN je Plattform und Betriebsmodell

Plattform	CDN	Eigenes CDN
AEM as a Cloud Service	Adobe-CDN auf Basis von Fastly, immer im Auslieferungspfad	nach Freigabe durch Adobe, vor dem Adobe-CDN (Adobe KA-35110)
AEM Edge Delivery Services	Fastly, von Adobe verwaltet	Fastly, Cloudflare, Akamai oder CloudFront (aem.live CDN Guide)
AEM 6.5 On-Premises und Managed Services	vom Betreiber gewählt	frei, vor dem Dispatcher
Magnolia DX Cloud	Fastly, Teil der verwalteten Infrastruktur	nach Abstimmung mit dem Hersteller
Magnolia selbst betrieben	vom Betreiber gewählt	frei, vor den Public-Instanzen

Bei AEM as a Cloud Service beschreibt Adobe das mitgelieferte CDN unter CDN in AEM as a Cloud Service. Steht ein eigenes CDN davor, bleibt Fastly im Pfad; geregelt werden muss dann, welche Schicht speichert und welche nur durchreicht, damit keine zwei Caches mit widersprüchlichen Regeln entstehen. Die Grundlagen der Plattformen stehen unter Adobe Experience Manager Performance und Magnolia CMS Performance.

Cache-Schlüssel im CDN: Parameter, Cookies und Header bestimmen die Trefferquote

Das CDN speichert eine Antwort unter einem Schlüssel, in der Regel aus Host, Pfad und Parametern. Jede Abweichung im Schlüssel erzeugt einen neuen Eintrag und damit einen Fehltreffer. Drei Quellen treiben die Zahl der Varianten:

• Parameter: Kampagnenparameter wie utm_source, gclid oder fbclid ändern den Inhalt nicht, erzeugen aber eindeutige Adressen. Sie gehören vor der Speicherung aus dem Schlüssel entfernt. Adobe tut das im CDN von AEM as a Cloud Service für die gängigen Parameter seit Oktober 2023 selbst, eigene Kampagnenparameter nicht.
• Cookies und Sitzungen: Ein Cookie, das für anonyme Besucher gesetzt wird, macht jede Antwort individuell, wenn das CDN Anfragen mit Cookies nicht speichert. Die Regel lautet: anonyme Seiten ohne Sitzung ausliefern.
• Vary-Header: Vary: User-Agent oder Vary: Cookie vervielfacht die Varianten. Geräteabhängige Ausgaben lassen sich besser über wenige normierte Gerätegruppen abbilden als über den vollständigen User-Agent.

Dieselben Regeln gelten eine Ebene tiefer für den AEM Dispatcher Cache und den Magnolia Cache. Die Liste ignorierter und wirksamer Parameter wird am besten einmal geführt und für CDN und Plattform-Cache gemeinsam gepflegt.

TTL und Invalidierung im CDN: Cache-Control, stale-while-revalidate und Purge per Tag

Wie lange das CDN eine Antwort hält, steuern die Header der Plattform. Mit s-maxage gilt eine eigene Lebensdauer für gemeinsam genutzte Caches wie das CDN, unabhängig von der Lebensdauer im Browser (RFC 9111). Mit stale-while-revalidate liefert das CDN nach Ablauf noch die bisherige Fassung aus, während es im Hintergrund die neue holt (RFC 5861). Damit trifft kein Besucher auf die Wartezeit einer Neuerzeugung.

Kurze Lebensdauern sind oft eine Folge fehlender Invalidierung: Weil Änderungen schnell sichtbar sein sollen, wird nur wenige Minuten gespeichert. Besser ist eine lange Lebensdauer mit gezieltem Löschen bei Veröffentlichung. Die großen CDNs löschen dafür nach Kennzeichen statt nach Adresse: Akamai über Cache Tags im Header Edge-Cache-Tag, Cloudflare über Cache-Tags im Header Cache-Tag, Fastly über Surrogate Keys. Eine Seite trägt die Kennzeichen der Inhalte, die sie anzeigt; wird ein Inhalt veröffentlicht, verschwinden genau die Seiten, die ihn enthalten, und nicht der ganze Cache.

Trefferquote messen: Logs des CDN je Seitentyp statt eines Gesamtwerts

Ein Gesamtwert über alle Anfragen ist meist hoch, weil Bilder, Schriften und Skripte gut gespeichert werden. Für die Antwortzeit zählt die Trefferquote der HTML-Seiten, getrennt nach Seitentyp und Markt. Sie steht in den Logs des CDN. Bei AEM as a Cloud Service sind diese Logs über den Cloud Manager für sieben Tage abrufbar (Adobe KA-52839); für längere Auswertungen werden sie per Log Forwarding in eine eigene Auswertung weitergeleitet.

Zwei Auswertungen gehören in jede Prüfung: die Trefferquote je Seitentyp im Verlauf, damit ein Release mit neuem Parameter oder neuer Sitzung sofort auffällt, und die Antwortzeit der Fehltreffer, also der Plattform selbst. Liegt die zweite deutlich über einer Sekunde, hilft auch ein besseres CDN nur den Treffern. Eine Zwischenebene zwischen den Knoten und der Plattform, je nach Anbieter Origin Shield, Shielding oder Tiered Cache genannt, bündelt die Fehltreffer und senkt die Last auf der Plattform zusätzlich.

Grenzen eines CDN: Hebel für TTFB und LCP, kaum Wirkung auf INP und CLS

Ein CDN verkürzt die Auslieferung. Was danach im Browser geschieht, bleibt unberührt: Interaction to Next Paint entsteht aus Skripten, Tags und Einwilligungsdialogen, Cumulative Layout Shift aus nachladenden Bereichen ohne reservierten Platz. Auch beim Largest Contentful Paint wirkt das CDN nur auf den ersten Abschnitt bis zum ersten Byte und auf die Ladezeit des Bildes.

Einen zusätzlichen Hebel bietet der Statuscode 103 Early Hints: Das CDN schickt dem Browser die Hinweise auf Stylesheets, Schriften oder das Hauptbild, bevor die eigentliche Antwort fertig ist. Akamai, Cloudflare und Fastly unterstützen das, mit unterschiedlicher Einrichtung (Akamai, Cloudflare, Fastly, dort nur über HTTP/2 und HTTP/3). Wirksam ist das vor allem bei Fehltreffern, weil der Browser die Wartezeit auf die Plattform nutzt.

Abnahmekriterien für das CDN: messbare Vorgaben je Seitentyp

• Für jeden Seitentyp ist eine Ziel-Trefferquote im CDN festgelegt und wird monatlich aus den Logs berichtet.
• Die Liste ignorierter Parameter ist dokumentiert und für CDN und Plattform-Cache gleich.
• Anonyme Seiten werden ohne Sitzungs-Cookie ausgeliefert.
• Veröffentlichungen löschen per Kennzeichen, nicht den ganzen Cache.
• Die Time to First Byte liegt im 75. Perzentil der Felddaten je Markt unter 800 Millisekunden, gemessen im Real User Monitoring und im Chrome User Experience Report.

Wie solche Vorgaben als Tickets formuliert werden, zeigen die Core Web Vitals Abnahmekriterien.

Kostenfreie Performance-Erstanalyse buchen

30 Minuten per Video. Sie sehen, ob Ihre Antwortzeit im CDN, im Plattform-Cache oder im Frontend entsteht.

Häufige Fragen zum CDN auf Enterprise-Plattformen