AEM Dispatcher Cache Trefferquote je Seitentyp messen, Query-Parameter und Invalidierung begrenzen, Antwortzeit senken

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

Der Dispatcher entscheidet auf einer Plattform mit Adobe Experience Manager darüber, wie schnell der Server antwortet. Trifft der Cache, liefert Apache eine fertige Datei aus. Verfehlt er, rechnet die Publish-Instanz die Seite neu, und die Time to First Byte steigt für jeden Besucher dieser Anfrage. Diese Seite beschreibt, woran der Dispatcher-Cache in der Praxis scheitert und welche Einstellungen die Trefferquote je Seitentyp erhöhen.

Im AEM Core Web Vitals Benchmark 2026 ist bei 80,3 Prozent der AEM-Auftritte mit zu langsamem Hauptinhalt bereits die Antwortzeit des Servers zu hoch, im Median 1.565 Millisekunden. Als gut gelten laut Google bis zu 800 Millisekunden. Bei diesen Auftritten beginnt die Analyse bei Server, Cache und Weiterleitungen, bevor das Frontend an die Reihe kommt.

AEM Dispatcher: Cache und Filter vor den Publish-Instanzen

Der Dispatcher ist ein Modul für den Apache HTTP Server. Er filtert Anfragen, leitet sie an die Publish-Instanzen weiter und legt die Antworten als Dateien im Dokumentverzeichnis ab. Die nächste Anfrage auf dieselbe Adresse beantwortet Apache direkt aus dem Dateisystem, ohne dass AEM arbeitet.

Zwischengespeichert wird eine Antwort nur, wenn unter anderem diese Bedingungen gleichzeitig erfüllt sind:

• Die Anfrage nutzt die Methode GET oder HEAD, und die Adresse hat eine Dateiendung wie .html.
• Die Adresse enthält keine Query-Parameter, es sei denn, sie sind über /ignoreUrlParams ausdrücklich freigegeben.
• Die Anfrage enthält keine Anmeldedaten, solange /allowAuthorized nicht gesetzt ist.
• Die Regeln unter /cache/rules lassen den Pfad zu, und die Antwort verbietet das Zwischenspeichern nicht, etwa über Dispatcher: no-cache oder Cache-Control: no-cache.

Jede dieser Bedingungen ist in gewachsenen Projekten eine eigene Fehlerquelle. Adobe beschreibt die Logik ausführlich in Understanding caching.

Trefferquote je Seitentyp: die Kennzahl für den Dispatcher-Cache

Eine Trefferquote für die ganze Plattform verdeckt das Problem. Startseite und Navigationsseiten treffen den Cache meist gut, während Produktdetailseiten, Suchergebnisse oder Seiten mit Kampagnenverkehr ihn häufiger verfehlen. Aussagekräftig ist deshalb die Trefferquote je Seitentyp, zusammen mit der Antwortzeit der Publish-Instanz bei einem Fehltreffer.

• AEM 6.5 und Adobe Managed Services: Das Dispatcher-Log zeigt für jede Anfrage, ob sie aus dem Cache kam. Den Grund für einen Fehltreffer, etwa Query-Parameter, nennt es im Debug-Loglevel oder als Antwortkopf, wenn die Anfrage den Kopf X-Dispatcher-Info trägt.
• AEM as a Cloud Service: Vor dem Dispatcher liegt das CDN von Adobe. Die CDN-Logs aus dem Cloud Manager zeigen, ob das CDN eine Anfrage aus dem Cache beantwortet hat, das Dispatcher-Log zeigt dasselbe für den Dispatcher. Zusammen ergibt sich, auf welcher Ebene eine Anfrage beantwortet wurde.
• Felddaten: Ob die Trefferquote reicht, zeigt die Time to First Byte echter Besucher je Seitentyp, gemessen wie unter Core Web Vitals messen beschrieben.

Query-Parameter im AEM Dispatcher: Kampagnenparameter über ignoreUrlParams freigeben

Der häufigste Fehltreffer entsteht durch Parameter, die den Inhalt der Seite gar nicht verändern. Ein Link aus einem Newsletter mit utm_source, eine Anzeige mit gclid oder ein Beitrag in sozialen Netzwerken mit fbclid erzeugt eine Adresse mit Query-String, und ohne Freigabe landet jede dieser Anfragen auf der Publish-Instanz. Kampagnenverkehr gehört damit oft zum langsamsten Verkehr der Plattform, obwohl für ihn bezahlt wird.

Abhilfe schafft /ignoreUrlParams im Abschnitt /cache. Adobe empfiehlt, Parameter grundsätzlich zu ignorieren und nur die ausdrücklich auszunehmen, die das HTML verändern, etwa den Suchbegriff einer Suchseite. Enthält eine Adresse einen einzigen nicht ignorierten Parameter, wird die gesamte Anfrage nicht zwischengespeichert. Im Cloud Service gehört zusätzlich das CDN dazu, weil dessen Cache-Schlüssel die vollständige Adresse enthält. Gängige Marketing-Parameter wie utm_*, gclid und fbclid entfernt das CDN bei Umgebungen ab Oktober 2023 standardmäßig selbst, eigene Kampagnenparameter nicht. Adobe beschreibt beides unter Caching in AEM as a Cloud Service.

Invalidierung im Dispatcher: statfileslevel begrenzt, was nach einer Aktivierung geleert wird

Nach jeder Aktivierung einer Seite meldet AEM dem Dispatcher, dass Inhalte veraltet sind. Welche Dateien dadurch ungültig werden, steuern die .stat-Dateien und der Wert /statfileslevel. Bei 0 liegt eine einzige .stat-Datei im Wurzelverzeichnis des Caches, und jede Aktivierung erklärt alle automatisch invalidierten Dateien dieses Verzeichnisses für veraltet. Teilen sich Sites und Sprachen ein Cache-Verzeichnis, wie in Adobes Standardkonfiguration, trifft das alle. Ein höherer Wert legt .stat-Dateien in tieferen Verzeichnissen an und begrenzt die Invalidierung auf den betroffenen Teilbaum.

Wie grob die Invalidierung greift, zeigt sich in redaktionsstarken Zeiten. Veröffentlicht eine Redaktion im Minutentakt, arbeitet eine Plattform mit zu niedrigem statfileslevel faktisch ohne Cache. Zwei weitere Einstellungen mildern das ab:

• /gracePeriod erlaubt, eine gerade invalidierte Datei noch für einige Sekunden auszuliefern, damit eine Welle von Aktivierungen nicht jede Anfrage auf die Publish-Instanz schickt.
• /serveStaleOnError liefert eine invalidierte, aber noch gespeicherte Fassung aus, wenn die Publish-Instanz mit 502, 503 oder 504 antwortet oder nicht rechtzeitig reagiert.

Inhalte, die auf vielen Seiten stehen, etwa Kopf und Fuß als Experience Fragments, brauchen eine eigene Invalidierungsregel. Ohne sie bleiben nach einer Änderung veraltete Fassungen im Cache, mit einer zu breiten Regel werden sehr viele Seiten neu erzeugt. Ein eigener, separat zwischengespeicherter Abruf für solche Bausteine löst beides.

Personalisierung im Dispatcher-Cache: einzelne Bausteine nachladen statt ganzer Seiten

Ein einziger personalisierter Baustein reicht, um eine ganze Seite vom Cache auszuschließen. Sling Dynamic Include löst das, indem der Baustein im zwischengespeicherten HTML durch einen Platzhalter ersetzt wird, den der Webserver per Server Side Include, das CDN per Edge Side Include oder der Browser per JavaScript separat füllt. Die Seite bleibt im Cache, nur der Baustein wird je Besucher erzeugt.

Wird der Baustein erst im Browser geladen, braucht er einen reservierten Platz in fester Höhe. Ohne diese Reservierung verschiebt er beim Nachladen das Layout und verschlechtert den Cumulative Layout Shift. Welche Bausteine serverseitig und welche im Browser entstehen, gehört je Seitentyp entschieden und schriftlich festgehalten.

AEM as a Cloud Service: CDN und Dispatcher als zwei Cache-Ebenen

Im Cloud Service liegt vor dem Dispatcher das CDN von Adobe. Wie lange HTML auf beiden Ebenen gültig bleibt, bestimmen die Cache-Header der Antwort, im Dispatcher zusammen mit der Invalidierung nach einer Aktivierung, sofern /enableTTL gesetzt ist, und die Dispatcher-Konfiguration wird in der Pipeline des Cloud Manager gegen Adobes Vorgaben geprüft. Diese Prüfung bewertet, ob die Konfiguration zulässig ist, nicht wie oft sie trifft. Eine Konfiguration kann jede Prüfung bestehen und trotzdem für Kampagnenverkehr oder personalisierte Seiten wirkungslos sein.

Bei einer Migration von AEM 6.5 in den Cloud Service wird die Dispatcher-Konfiguration häufig übernommen und an das neue Format angepasst. Die Trefferquote je Seitentyp gehört dabei vor und nach der Migration gemessen, wie unter AEM 6.5 Support-Ende beschrieben. Bei AEM Edge Delivery Services entfällt der Dispatcher, die Frage nach Cache-Schlüssel und Invalidierung stellt sich dort im CDN.

Dispatcher-Anforderungen im Lastenheft: messbar und abnehmbar

• Trefferquote je Seitentyp als laufende Kennzahl, mit Zielwert aus dem gemessenen Ausgangswert.
• Eine dokumentierte Liste ignorierter und wirksamer Query-Parameter, abgestimmt zwischen Dispatcher und CDN.
• Ein statfileslevel, der zur Struktur aus Sites und Sprachen passt, mit Nachweis des Verhaltens nach einer Aktivierung.
• Personalisierung bausteinweise, mit reserviertem Platz für alles, was im Browser nachgeladen wird.
• Abnahme gegen die Time to First Byte echter Besucher je Seitentyp, nicht gegen einen Laborwert.

Die vollständigen Formulierungen stehen in der Vorlage Performance-Anforderungen im AEM-Lastenheft. Was nach dem Server im Browser passiert, beschreibt AEM Client Libraries. Die Einordnung aller Ursachen auf AEM-Plattformen steht unter Adobe Experience Manager Performance.

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 zum AEM Dispatcher Cache