Personalisierung und Performance Was personalisierte Inhalte auf AEM und Magnolia an Cache-Treffern und Ladezeit kosten und wie sich der Preis begrenzen lässt
Personalisierung zeigt verschiedenen Besuchern verschiedene Inhalte. Für die Auslieferung bedeutet das: Eine Adresse hat mehrere gültige Antworten. Entweder speichert der Cache jede Variante einzeln, oder er wird umgangen, oder die Variante entsteht erst im Browser. Jeder Weg hat einen Preis, der sich in der Time to First Byte oder im Largest Contentful Paint zeigt.
Im Core Web Vitals Benchmark 2026 ist bei 80,3 Prozent der AEM-Auftritte und 78,8 Prozent der Magnolia-Auftritte mit zu langsamem Hauptinhalt bereits die Antwortzeit des Servers zu hoch. Personalisierung, die Seiten am Cache vorbeileitet, verschärft genau diesen Engpass.
Personalisierung im Cache: jede Variante ist ein eigener Eintrag
Personalisierung fügt dem Cache-Schlüssel ein Merkmal hinzu, etwa Segment, Region oder Gerät. Die Zahl der Einträge wächst mit dem Produkt der Varianten: Zwei personalisierte Bausteine mit je drei Varianten ergeben bis zu neun Fassungen derselben Seite, jede mit eigenem ersten Abruf.
- AEM Dispatcher: Ein einziger personalisierter Baustein reicht, um eine ganze Seite vom Cache auszuschließen (AEM Dispatcher Cache).
- Magnolia: In der Standardkonfiguration speichert Magnolia Seiten mit personalisierten Inhalten gar nicht (Magnolia Cache).
- CDN: Ohne eigene Regeln liefert ein CDN die erste gespeicherte Antwort an alle aus. Personalisierte Seiten werden deshalb oft pauschal vom CDN ausgenommen.
Clientseitige Personalisierung mit Adobe Target: Pre-Hiding verschiebt den Largest Contentful Paint
Clientseitig liefert der Cache eine einheitliche Seite, und ein Skript tauscht Inhalte im Browser aus. Die Trefferquote bleibt hoch, die Kosten wandern in den Seitenaufbau. Damit der Standardinhalt nicht aufblitzt, blendet Adobe Target die Seite bis zur Antwort aus:
- at.js: Das Pre-Hiding-Snippet setzt
body {opacity: 0 !important}und entfernt den Stil bei Antwort, Fehler oder Ablauf des Zeitgebers, standardmäßig nach 3.000 Millisekunden (Adobe: Manage flicker with at.js). - Web SDK: Das Platform Web SDK nutzt ein eigenes Snippet mit der Kennung
alloy-prehiding, im Beispiel ebenfalls mit 3.000 Millisekunden. Adobe empfiehlt, statt des ganzen Body nur die Container mit personalisierten Inhalten auszublenden (Adobe: Manage flicker with Web SDK).
Elemente mit einer Deckkraft von null zählen nicht als LCP-Element (web.dev). Der Largest Contentful Paint liegt deshalb mindestens beim Ende der Ausblendung. Ohne Ausblendung entsteht Flackern, ein ausgetauschtes Bühnenbild wird zum neuen, späteren LCP-Element, und der Austausch kann den Cumulative Layout Shift erhöhen.
Auf AEM-Seiten lässt die standardmäßig aktive Einstellung Use accurate targeting die Auslieferung auf den geladenen Kontext warten (Adobe). Bei Edge Delivery Services läuft der Abruf von Target in der ersten Ladephase und wirkt laut Adobe direkt auf den LCP (aem.live). Die Wirkung von Tags und Testwerkzeugen insgesamt beschreibt Drittanbieter-Skripte.
Serverseitige und hybride Personalisierung: Entscheidung vor dem ersten Byte
Fällt die Entscheidung auf dem Server oder im CDN, kommt die passende Fassung fertig beim Browser an, ohne Ausblendung und ohne Flackern. Google empfiehlt für Tests deshalb die serverseitige Umsetzung, wo sie möglich ist (Chrome for Developers). Adobe Target bietet dafür die Delivery API und Server-SDKs. In der hybriden Variante entscheidet der Server über die erste Ansicht, und das Skript im Browser übernimmt das Ergebnis; im Web SDK dient dafür seit Version 2.13.0 der Befehl applyResponse (Adobe: Hybrid personalization).
Der Preis wandert in die Antwortzeit: Der Server wartet auf die Entscheidung, und die Seite ist als Ganzes nicht mehr im Cache. Am günstigsten bleibt die Seite gespeichert, und nur einzelne Bausteine entstehen je Besucher.
| Weg | Cache | Ladezeit | Steuergröße |
|---|---|---|---|
| Clientseitig mit Pre-Hiding | Seite einheitlich im Cache | LCP mindestens bis Ende der Ausblendung | ausgeblendete Fläche und Timeout |
| Clientseitig ohne Pre-Hiding | Seite einheitlich im Cache | Flackern, späteres LCP-Element, Layoutverschiebung | reservierter Platz je Baustein |
| Seitenvarianten im Cache | ein Eintrag je Variantenkombination | schnell bei Treffer, langsam bei jedem ersten Abruf | Zahl aktiver Varianten |
| Bausteine per Include | Seite im Cache, Baustein separat | Antwortzeit des Bausteins kommt hinzu | Zahl und Dauer der Includes |
AEM: Sling Dynamic Include hält die Seite im Dispatcher-Cache
Sling Dynamic Include ersetzt einen personalisierten Baustein im gespeicherten HTML durch einen Platzhalter, den der Webserver per Server Side Include, ein CDN per Edge Side Include oder der Browser per JavaScript füllt (Adobe). Bei AEM as a Cloud Service unterstützt das mitgelieferte CDN auf Basis von Fastly derzeit kein Edge Side Include, Server Side Include über mod_include im Dispatcher funktioniert (Adobe KA-21610).
Die AEM-eigene Personalisierung arbeitet mit ContextHub, dessen Speicher im Browser liegen und dessen Segmente dort per JavaScript aufgelöst werden (Adobe: ContextHub). Experience Fragments lassen sich als Angebote nach Adobe Target exportieren (Adobe). Beide Wege sind clientseitig und folgen denselben Regeln für Ausblendung und reservierten Platz.
Magnolia: Segmente, Advanced Cache for Personalization und Varianten im CDN
Magnolia ordnet Besucher über Merkmale (Traits) Segmenten zu und spielt je Segment Varianten von Seiten oder Komponenten aus. Mit dem Modul Advanced Cache for Personalization aus DX Core wird jede Kombination der angefragten Varianten ein eigener Cache-Eintrag (Magnolia), mit jedem zusätzlichen Segment sinkt die Trefferquote. Das Modul für dynamisches Seiten-Caching speichert die Seite und rendert nur die dynamischen Komponenten je Anfrage.
Für Magnolia DX Cloud mit Fastly beschreibt Magnolia, wie das CDN Varianten trennt: Merkmale werden aus der Anfrage gelesen, auf wenige Kategorien normiert und über den Vary-Header in den Cache-Schlüssel übernommen. Geeignet sind Gerätetyp, Region und Segmente mit wenigen Ausprägungen, etwa drei bis fünf Gerätetypen; Merkmale aus Cookies haben meist zu viele Werte (Magnolia: Personalize content with CDN caching).
Variantenbudget, RUM-Messung und Abnahme: Personalisierung als steuerbare Kennzahl
- Obergrenze je Seitentyp: Höchstzahl gleichzeitig aktiver Varianten oder Segmente, festgehalten im Performance-Budget.
- Getrennte Messung: Im Real User Monitoring trägt jede Messung das Merkmal personalisiert oder nicht personalisiert, dazu die Aktivität. Erst so wird der Abstand im 75. Perzentil des LCP sichtbar.
- Timeout-Quote: Adobe beschreibt das Erreichen des Timeouts als seltenen Fall. Wie oft er eintritt, gehört je Seitentyp ausgewertet.
- Abnahme: Jede neue Aktivität nennt Seitentyp, Varianten und ausgeblendeten Bereich, reserviert Platz in fester Höhe und hält den Abstand im LCP unter einem vereinbarten Zielwert.
Wie solche Vorgaben als Tickets formuliert werden, zeigen die Core Web Vitals Abnahmekriterien.
Kostenfreie Performance-Erstanalyse buchen
30 Minuten per Video. Sie sehen, welchen Anteil Personalisierung und Testwerkzeuge an der Ladezeit Ihres Hauptinhalts haben.
Häufige Fragen zu Personalisierung und Performance
Verschlechtert Adobe Target den Largest Contentful Paint?
Clientseitig eingesetzt meist ja, weil das Pre-Hiding-Snippet die Seite oder Teile davon bis zur Antwort von Target ausblendet. Ausgeblendete Elemente zählen nicht als LCP-Element, der Wert liegt deshalb mindestens beim Ende der Ausblendung. Wie groß der Abstand ist, zeigt ein Real User Monitoring, das personalisierte und nicht personalisierte Aufrufe getrennt auswertet.
Wie viele Personalisierungsvarianten verträgt ein Cache?
Eine allgemeingültige Zahl gibt es nicht, weil jede Kombination von Varianten ein eigener Eintrag ist und die Trefferquote zusätzlich von Verkehr und Veröffentlichungsfrequenz abhängt. Magnolia nennt für die Trennung im CDN wenige Kategorien je Merkmal, etwa drei bis fünf Gerätetypen. Sinnvoll ist eine Obergrenze je Seitentyp im Performance-Budget, abgeleitet aus der gemessenen Trefferquote.
Ist serverseitige Personalisierung immer schneller?
Nein. Sie vermeidet Ausblendung und Flackern, verlagert die Wartezeit aber in die Antwortzeit des Servers. Wenn dadurch ganze Seiten am Cache vorbeigehen, steigt die Time to First Byte. Am günstigsten ist eine Seite, die im Cache bleibt, mit einzelnen Bausteinen, die per Include oder im CDN je Besucher entstehen.
Wie lässt sich der Einfluss der Personalisierung messen?
Im Real User Monitoring mit einem Merkmal je Messung, das angibt, ob der Aufruf personalisiert war, dazu Aktivität und Seitentyp. Verglichen wird das 75. Perzentil des LCP beider Gruppen. Ergänzend gehören die Timeout-Quote des Pre-Hiding und die Trefferquote personalisierter Seitentypen aus den Cache-Logs in die Auswertung.