AEM Dispatcher Cache Measure the cache hit ratio per page type, limit query parameters and invalidation, lower server response time

By Christian Schreiber, Web Performance Consultant for AEM, updated 1 November 2026

On an Adobe Experience Manager platform, the Dispatcher decides how fast the server responds. On a cache hit, Apache returns a finished file. On a miss, the publish instance renders the page again, and Time to First Byte rises for every visitor of that request. This page describes where the Dispatcher cache fails in practice and which settings raise the cache hit ratio per page type.

In the AEM Core Web Vitals Benchmark 2026, 80.3 percent of AEM websites with a slow main content load already have a server response time that is too high, 1,565 milliseconds at the median. Google rates up to 800 milliseconds as good. For these websites, analysis starts with server, cache and redirects before the frontend.

AEM Dispatcher: cache and filter in front of the publish instances

The Dispatcher is a module for the Apache HTTP Server. It filters requests, forwards them to the publish instances and stores the responses as files in the document root. The next request for the same URL is answered by Apache directly from the file system, without any work in AEM.

A response is only cached when, among others, these conditions are met at the same time:

• The request uses the GET or HEAD method, and the URL has a file extension such as .html.
• The URL contains no query parameters, unless they are explicitly allowed via /ignoreUrlParams.
• The request carries no credentials, as long as /allowAuthorized is not set.
• The rules under /cache/rules allow the path, and the response does not forbid caching, for example via Dispatcher: no-cache or Cache-Control: no-cache.

In mature projects, each of these conditions is a separate source of errors. Adobe documents the logic in detail in Understanding caching.

Cache hit ratio per page type: the key metric for the Dispatcher cache

A single cache hit ratio for the whole platform hides the problem. The homepage and navigation pages usually hit the cache well, while product detail pages, search results or pages with campaign traffic miss it more often. The meaningful figure is the cache hit ratio per page type, together with the response time of the publish instance on a miss.

• AEM 6.5 and Adobe Managed Services: The Dispatcher log shows for each request whether it came from the cache. The reason for a miss, such as query parameters, is given at debug log level or as a response header when the request carries the X-Dispatcher-Info header.
• AEM as a Cloud Service: Adobe's CDN sits in front of the Dispatcher. The CDN logs from Cloud Manager show whether the CDN answered a request from its cache, and the Dispatcher log shows the same for the Dispatcher. Together they show at which layer a request was answered.
• Field data: Whether the cache hit ratio is sufficient shows in the Time to First Byte of real visitors per page type, measured as described under Measuring Core Web Vitals.

Query parameters in the AEM Dispatcher: allow campaign parameters via ignoreUrlParams

The most frequent cache miss comes from parameters that do not change the content of the page at all. A newsletter link with utm_source, an ad with gclid or a social media post with fbclid creates a URL with a query string, and without an exception every one of these requests reaches the publish instance. Campaign traffic, the traffic you pay for, thus often becomes some of the slowest traffic on the platform.

The fix is /ignoreUrlParams in the /cache section. Adobe recommends ignoring parameters by default and excluding only those that change the HTML, such as the query term of a search page. If a URL contains a single parameter that is not ignored, the whole request is not cached. In AEM as a Cloud Service, the CDN has to be considered as well, because its cache key contains the full URL. For environments created from October 2023, the CDN removes common marketing parameters such as utm_*, gclid and fbclid by default, but not custom campaign parameters. Adobe describes both under Caching in AEM as a Cloud Service.

Dispatcher invalidation: statfileslevel limits what is cleared after an activation

After every page activation, AEM tells the Dispatcher that content is outdated. Which files become invalid is controlled by the .stat files and the /statfileslevel value. At 0, a single .stat file sits in the root directory of the cache, and every activation marks all auto-invalidated files of that directory as outdated. If sites and languages share one cache directory, as in Adobe's default configuration, all of them are affected. A higher value creates .stat files in deeper directories and limits invalidation to the affected subtree.

How coarse invalidation is becomes visible at busy editorial times. When editors publish every few minutes, a platform with a statfileslevel that is too low effectively runs without a cache. Two more settings soften the effect:

• /gracePeriod allows a freshly invalidated file to be served for a few more seconds, so a wave of activations does not send every request to the publish instance.
• /serveStaleOnError serves an invalidated but still stored version when the publish instance responds with 502, 503 or 504 or does not respond in time.

Content that appears on many pages, such as header and footer as Experience Fragments, needs its own invalidation rule. Without it, outdated versions remain in the cache after a change; with a rule that is too broad, a large number of pages are regenerated. A separate, separately cached request for such building blocks solves both.

Personalization and the Dispatcher cache: load single components, not whole pages

One personalized component is enough to exclude an entire page from the cache. Sling Dynamic Include solves this by replacing the component in the cached HTML with a placeholder that the web server fills via Server Side Include, the CDN via Edge Side Include or the browser via JavaScript. The page stays in the cache, and only the component is generated per visitor.

If the component is loaded in the browser, it needs a reserved space with a fixed height. Without that reservation it shifts the layout when it loads and worsens Cumulative Layout Shift. Which components are rendered on the server and which in the browser should be decided per page type and documented.

AEM as a Cloud Service: CDN and Dispatcher as two cache layers

In AEM as a Cloud Service, Adobe's CDN sits in front of the Dispatcher. How long HTML stays valid on both layers is defined by the cache headers of the response, in the Dispatcher together with invalidation after an activation, provided /enableTTL is set, and the Cloud Manager pipeline validates the Dispatcher configuration against Adobe's rules. That validation checks whether the configuration is allowed, not how often it hits. A configuration can pass every check and still be ineffective for campaign traffic or personalized pages.

When migrating from AEM 6.5 to the Cloud Service, the Dispatcher configuration is often carried over and adapted to the new format. The cache hit ratio per page type should be measured before and after the migration, as described under AEM 6.5 End of Support. With AEM Edge Delivery Services the Dispatcher disappears, and the questions of cache key and invalidation move to the CDN.

Dispatcher requirements in the specification: measurable and ready for sign-off

• Cache hit ratio per page type as an ongoing metric, with a target value derived from the measured baseline.
• A documented list of ignored and effective query parameters, aligned between Dispatcher and CDN.
• A statfileslevel that matches the structure of sites and languages, with proof of the behavior after an activation.
• Personalization per component, with reserved space for everything loaded in the browser.
• Sign-off against the Time to First Byte of real visitors per page type, not against a lab value.

The complete wording is in the template AEM Performance Requirements Template. What happens in the browser after the server responds is covered in AEM Client Libraries. All causes on AEM platforms are put in context under Adobe Experience Manager 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 AEM Dispatcher cache