Magnolia Cache Align cache configuration, flush strategy and personalization variants so the public instances are relieved
On a Magnolia platform, the page cache of the public instances, possibly complemented by a CDN in front, decides how fast the server responds. On a hit, the page comes ready-made from storage. On a miss, the public instance renders templates, components and queries again, and Time to First Byte rises. This page describes how the Magnolia cache module decides, where the cache hit ratio fails in projects and which settings raise it.
In the Magnolia CMS Core Web Vitals Benchmark 2026, 78.8 percent of Magnolia websites with a slow main content load already have a server response time that is too high, 1,668 milliseconds at the median. Across all websites checked, 57.4 percent keep the response time in the good range, which Google sets at up to 800 milliseconds.
Magnolia cache module: cache policy, voters and executors
The Magnolia cache module sits in front of rendering on the public instance. It is configured under /modules/cache/config/contentCaching/, for pages in the defaultPageCache entry. Three building blocks define its behavior:
- Cache policy: decides per request whether the response comes from the cache, is stored or bypasses the cache.
- Voters: rules the policy uses to decide, for example by URL, file type or parameters.
- Executors: carry out the decision, that is serve from the cache, store or bypass.
In addition, the browser cache policy sets the cache headers for browsers and upstream caches such as a CDN. Magnolia documents the configuration under Cache core.
Parameters and sessions in the Magnolia cache: the most common causes of misses
Campaign parameters such as utm_source or gclid do not change the content of a page, but in the default configuration Magnolia does not cache requests with parameters. Since Magnolia 6.2.30, parameters can be stored as a regular expression under cachePolicy/shouldBypassVoters/deny/parameters/whitelist, for example ^utm_.*$, whose requests are then cached. The parameter remains part of the cache key: recurring values such as utm_source=newsletter benefit, unique values such as gclid still cause misses and are better removed from the key in the CDN in front of Magnolia.
The second cause is sessions and cookies for anonymous visitors. If a component, a form or an extension creates a session for every visitor, every response can become individual. The check is simple: an anonymous request for a content page should neither create a session nor set a cookie that changes the response.
Flush strategy in Magnolia: limit clearing after publication
In the default configuration, Magnolia clears the cache on publication events. Which workspaces trigger a flush can be narrowed down via excludedWorkspaces. When editors publish frequently, a platform with a coarse flush strategy effectively runs without a cache at busy editorial times, and every first request after a flush hits the public instance.
The advanced cache modules of Magnolia DX Core offer two strategies for this, described under Advanced cache modules:
- Serve until recached: after a change, the old entry is kept. The first request generates the new one, and all others receive the previous version until then.
- Eager recaching: the cache keeps a list of the most requested entries and regenerates them right after a change, all others on the next request.
On platforms with several sites, a site-aware flush policy can limit clearing to the affected site. Which option fits depends on publication frequency and freshness requirements and should be decided per page type.
Personalization in the Magnolia cache: every variant is a separate entry
In the default configuration, Magnolia does not cache pages with personalized content, and the public instance renders every request again. With the Advanced Cache for Personalization module of DX Core, every variant becomes a separate cache entry, and the cache hit ratio drops with every additional segment. The dynamic page caching module of DX Core caches the page and renders only the dynamic components per request.
- An upper limit for segments active at the same time per page type, recorded in the performance budget.
- Personalization limited to single components instead of splitting whole pages into variants.
- Components loaded in the browser with reserved space of fixed height, so that Cumulative Layout Shift does not rise.
CDN in front of Magnolia: align cache headers and invalidation
If a CDN or reverse proxy sits in front of the public instances, there are two cache layers with their own rules. The cache headers from the browser cache policy define how long the CDN keeps a page, unless the CDN overrides them with its own rules or a Surrogate-Control header, and a publication in Magnolia does not clear the CDN automatically. Without aligned lifetimes and invalidation, either the CDN serves outdated pages or lifetimes are set so short that it hardly relieves the platform. The CDN cache key needs the same rules for campaign parameters as Magnolia itself. For Magnolia DX Cloud with Fastly as CDN, Magnolia describes in the documentation of the platform service how to automate clearing the CDN after a publication.
Cache requirements in the Magnolia specification: cache hit ratio as a metric
- Cache hit ratio per page type as an ongoing metric, with a target value derived from the measured baseline.
- A documented list of ignored parameters, identical in Magnolia and CDN.
- A flush strategy that matches the publication frequency, with proof of the behavior after a publication.
- No sessions and no individualizing cookies for anonymous visitors on content pages.
- Sign-off against the Time to First Byte of real visitors per page type.
The complete wording is in the Magnolia Performance Requirements Template. How the cache behaves with a separate frontend is described in Magnolia Headless. All causes on Magnolia platforms are put in context under Magnolia CMS Performance.
Book a free performance analysis
30 minutes by video. You receive Google's real-user data for your platform compared with two competitors, whether or not a collaboration follows.
Frequently asked questions about the Magnolia cache
Why does Magnolia clear the cache after a publication?
So that visitors do not receive outdated pages. In the default configuration, a publication event triggers the flush. With frequent publications, this lowers the cache hit ratio considerably. Remedies are narrowing the triggering workspaces or, in DX Core, a site-aware flush policy and the strategies of the advanced cache modules, which serve the previous version until the new one is generated.
How can campaign parameters be ignored in the Magnolia cache?
Since Magnolia 6.2.30, parameters can be stored as a regular expression under cachePolicy/shouldBypassVoters/deny/parameters/whitelist, for example ^utm_.*$. Requests with these parameters are then cached and answered from the cache for the same parameter value. Unique values such as gclid are better removed from the cache key by an upstream CDN.
How does personalization affect the Magnolia cache?
In the default configuration, pages with personalized content are not cached at all. With the Advanced Cache for Personalization module of DX Core, every variant is a separate cache entry, and with every additional segment the cache hit ratio drops. What works is an upper limit for active segments per page type and limiting personalization to single components.