Magnolia Cache Cache-Konfiguration, Flush-Strategie und Personalisierungsvarianten so abstimmen, dass die Public-Instanzen entlastet werden
Auf einer Magnolia-Plattform entscheidet der Seitencache der Public-Instanzen, gegebenenfalls ergänzt um ein CDN davor, darüber, wie schnell der Server antwortet. Trifft er, kommt die Seite fertig aus dem Speicher. Verfehlt er, rendert die Public-Instanz Templates, Komponenten und Abfragen neu, und die Time to First Byte steigt. Diese Seite beschreibt, wie das Cache-Modul von Magnolia entscheidet, woran die Trefferquote in Projekten scheitert und welche Einstellungen sie erhöhen.
Im Magnolia CMS Core Web Vitals Benchmark 2026 ist bei 78,8 Prozent der Magnolia-Auftritte mit zu langsamem Hauptinhalt bereits die Antwortzeit des Servers zu hoch, im Median 1.668 Millisekunden. Über alle geprüften Auftritte halten 57,4 Prozent die Antwortzeit im guten Bereich, den Google bis 800 Millisekunden ansetzt.
Magnolia-Cache-Modul: Cache Policy, Voter und Executors
Das Cache-Modul von Magnolia steht vor dem Rendering der Public-Instanz. Konfiguriert wird es unter /modules/cache/config/contentCaching/, für Seiten im Eintrag defaultPageCache. Drei Bausteine bestimmen das Verhalten:
- Cache Policy: entscheidet je Anfrage, ob die Antwort aus dem Cache kommt, gespeichert oder am Cache vorbeigeleitet wird.
- Voter: Regeln, mit denen die Policy entscheidet, etwa nach Adresse, Dateityp oder Parametern.
- Executors: führen die Entscheidung aus, also aus dem Cache liefern, speichern oder umgehen.
Dazu kommt die Browser Cache Policy, die die Cache-Header für Browser und vorgelagerte Caches wie ein CDN setzt. Magnolia beschreibt die Konfiguration unter Cache core.
Parameter und Sitzungen im Magnolia Cache: die häufigsten Ursachen für Fehltreffer
Kampagnenparameter wie utm_source oder gclid verändern den Inhalt einer Seite nicht, in der Standardkonfiguration speichert Magnolia Anfragen mit Parametern aber nicht im Cache. Seit Magnolia 6.2.30 lassen sich unter cachePolicy/shouldBypassVoters/deny/parameters/whitelist Parameter als regulärer Ausdruck hinterlegen, etwa ^utm_.*$, deren Anfragen dann gespeichert werden. Der Parameter bleibt dabei Teil des Cache-Schlüssels: Wiederkehrende Werte wie utm_source=newsletter profitieren, eindeutige Werte wie gclid erzeugen weiter Fehltreffer und werden besser vor Magnolia im CDN aus dem Schlüssel entfernt.
Die zweite Ursache sind Sitzungen und Cookies für anonyme Besucher. Legt eine Komponente, ein Formular oder eine Erweiterung für jeden Besucher eine Sitzung an, kann jede Auslieferung individuell werden. Die Prüfung ist einfach: Eine anonyme Anfrage auf eine Inhaltsseite sollte weder eine Sitzung erzeugen noch ein Cookie setzen, das die Antwort verändert.
Flush-Strategie in Magnolia: Leeren nach Veröffentlichung gezielt begrenzen
In der Standardkonfiguration leert Magnolia den Cache bei Veröffentlichungsereignissen. Welche Workspaces einen Flush auslösen, lässt sich über excludedWorkspaces eingrenzen. Veröffentlicht eine Redaktion häufig, arbeitet die Plattform mit einer groben Flush-Strategie in redaktionsstarken Zeiten faktisch ohne Cache, und jede erste Anfrage nach einem Flush trifft die Public-Instanz.
Die Advanced-Cache-Module von Magnolia DX Core bieten dafür zwei Strategien, beschrieben unter Advanced cache modules:
- Ausliefern bis zur Neuerzeugung: Nach einer Änderung bleibt der alte Eintrag erhalten. Die erste Anfrage erzeugt den neuen, alle weiteren erhalten bis dahin die bisherige Fassung.
- Vorzeitiges Neuerzeugen: Der Cache führt eine Liste der am häufigsten abgerufenen Einträge und erzeugt sie nach einer Änderung sofort neu, alle übrigen erst beim nächsten Abruf.
Bei Plattformen mit mehreren Sites kann eine siteabhängige Flush-Policy das Leeren auf die betroffene Site begrenzen. Welche Variante passt, hängt von Veröffentlichungsfrequenz und Aktualitätsanforderungen ab und gehört je Seitentyp entschieden.
Personalisierung im Magnolia Cache: jede Variante ist ein eigener Eintrag
In der Standardkonfiguration speichert Magnolia Seiten mit personalisierten Inhalten nicht im Cache, jede Anfrage rendert die Public-Instanz neu. Mit dem Modul Advanced Cache for Personalization aus DX Core wird jede Variante ein eigener Cache-Eintrag, und die Trefferquote sinkt mit jedem zusätzlichen Segment. Das Modul für dynamisches Seiten-Caching aus DX Core speichert die Seite und rendert nur die dynamischen Komponenten je Anfrage.
- Eine Obergrenze für gleichzeitig aktive Segmente je Seitentyp, festgehalten im Performance-Budget.
- Personalisierung auf einzelne Bausteine begrenzen, statt ganze Seiten in Varianten zu teilen.
- Bausteine, die im Browser nachgeladen werden, mit reserviertem Platz in fester Höhe, damit der Cumulative Layout Shift nicht steigt.
CDN vor Magnolia: Cache-Header und Invalidierung abstimmen
Liegt ein CDN oder Reverse Proxy vor den Public-Instanzen, entstehen zwei Cache-Ebenen mit eigenen Regeln. Die Cache-Header aus der Browser Cache Policy bestimmen, wie lange das CDN eine Seite hält, sofern das CDN sie nicht über eigene Regeln oder einen Surrogate-Control-Header übersteuert, und eine Veröffentlichung in Magnolia leert das CDN nicht automatisch. Ohne abgestimmte Laufzeiten und Invalidierung liefert entweder das CDN veraltete Seiten, oder die Laufzeiten werden so kurz gesetzt, dass es kaum entlastet. Der Cache-Schlüssel des CDN braucht dieselben Regeln für Kampagnenparameter wie Magnolia selbst. Für Magnolia DX Cloud mit Fastly als CDN beschreibt Magnolia in der Dokumentation des Plattformdienstes, wie sich das Leeren des CDN nach einer Veröffentlichung automatisieren lässt.
Cache-Anforderungen im Magnolia-Lastenheft: Trefferquote als Kennzahl
- Trefferquote je Seitentyp als laufende Kennzahl, mit Zielwert aus dem gemessenen Ausgangswert.
- Eine dokumentierte Liste ignorierter Parameter, gleich in Magnolia und CDN.
- Eine Flush-Strategie, die zur Veröffentlichungsfrequenz passt, mit Nachweis des Verhaltens nach einer Veröffentlichung.
- Keine Sitzungen und keine individualisierenden Cookies für anonyme Besucher auf Inhaltsseiten.
- Abnahme gegen die Time to First Byte echter Besucher je Seitentyp.
Die vollständigen Formulierungen stehen in der Vorlage Performance-Anforderungen im Magnolia-Lastenheft. Wie sich der Cache bei einem eigenen Frontend verhält, beschreibt Magnolia Headless. Alle Ursachen auf Magnolia-Plattformen ordnet Magnolia CMS 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 zum Magnolia Cache
Warum leert Magnolia den Cache nach einer Veröffentlichung?
Damit Besucher keine veralteten Seiten erhalten. In der Standardkonfiguration löst ein Veröffentlichungsereignis den Flush aus. Bei häufigen Veröffentlichungen senkt das die Trefferquote stark. Abhilfe schaffen eine Eingrenzung der auslösenden Workspaces oder, in DX Core, eine siteabhängige Flush-Policy und die Strategien der Advanced-Cache-Module, die bis zur Neuerzeugung die bisherige Fassung ausliefern.
Wie lassen sich Kampagnenparameter im Magnolia Cache ignorieren?
Seit Magnolia 6.2.30 können Parameter unter cachePolicy/shouldBypassVoters/deny/parameters/whitelist als regulärer Ausdruck hinterlegt werden, etwa ^utm_.*$. Anfragen mit diesen Parametern werden dann gespeichert und bei gleichem Parameterwert aus dem Cache beantwortet. Eindeutige Werte wie gclid entfernt besser ein vorgelagertes CDN aus dem Cache-Schlüssel.
Wie wirkt sich Personalisierung auf den Magnolia Cache aus?
In der Standardkonfiguration werden Seiten mit personalisierten Inhalten gar nicht zwischengespeichert. Mit dem Modul Advanced Cache for Personalization aus DX Core ist jede Variante ein eigener Cache-Eintrag, und mit jedem zusätzlichen Segment sinkt die Trefferquote. Wirksam sind eine Obergrenze für aktive Segmente je Seitentyp und die Begrenzung der Personalisierung auf einzelne Bausteine.