AEM and SSI for Dynamic Content in the Dispatcher
When Adobe Experience Manager renders a page, the temptation is to push everything through the platform and rely on its own caching layers. That works for static marketing copy, but the moment a fragment depends on the visitor, the session, or a downstream system, response time can balloon. Server-Side Includes offer a way to compose a page from independently cacheable pieces while still serving a single HTML document from the Dispatcher.
Architects running AEM for high-traffic sites across the Asia-Pacific region often settle on a hybrid model: a cached outer template, with smaller personalised blocks pulled at request time through SSI directives. It keeps the bulk of the response inside the Dispatcher cache, leaves the personalised edge flexible, and avoids the brittle iframes and heavy client-side waterfalls that haunted older implementations.
How SSI slots into the AEM Dispatcher pipeline
Server-Side Includes are an old Apache feature, predating most JavaScript frameworks, and that heritage is part of why they remain useful. The web server, not the application server, does the assembly. With mod_include enabled and the right MIME mapping for .shtml, Apache can evaluate <!--#include virtual="/path" --> directives after it retrieves the cached outer page from the Dispatcher.
The Dispatcher itself is essentially an Apache module that sits in front of AEM's authoring and publish instances. It caches rendered HTML and only contacts AEM when content is missing, stale, or explicitly invalidated. SSI extends that model: individual fragments can each be cached at the edge with their own headers, while the outer page simply stitches them together.
| Approach | Where the assembly happens | Cache granularity | Typical latency cost | Browser dependency |
|---|---|---|---|---|
| Server-Side Includes | Apache web server, post-Dispatcher | Per fragment file | One extra internal sub-request | None |
| Edge-Side Includes (ESI) | CDN or reverse proxy | Per fragment block | Single origin hit plus cache lookup | None |
Client-side fetch + DOM injection |
User's browser | Per API call | Network round trip per block | JavaScript required |
| Iframes | Browser layout engine | Per iframe document | Independent page load | None |
For teams who already maintain an Apache layer in front of AEM, SSI is often the path of least resistance. ESI is faster at global scale but requires a CDN that supports it, and the broader open-source community regularly discusses when the added operational complexity of ESI is justified versus plain SSI on the Dispatcher.
Configuring Apache for SSI behind the Dispatcher
The technical setup is straightforward but the choices matter. Out of the box, Apache only honours SSI on pages that carry a parsed MIME type, which is why .shtml files are conventional. With AEM, however, output rarely lives as .shtml. A common pattern is to add a Content-Type negotiation step or a Filter chain that re-marks the response for parsing, then restrict SSI to specific virtual paths so untrusted content never gets evaluated.
Two mod_include directives carry most of the weight: Options +Includes on a <Location> block scoped to dynamic fragments, and SetOutputFilter INCLUDES for those paths. Teams usually pair this with SSIRequireFlush on the outer cached page so fragment changes propagate immediately, without waiting for the Dispatcher flush agent.
Security deserves attention. SSI directives run with the Apache worker's privileges and can read local files or invoke internal sub-requests. Stripping any user-supplied HTML before caching, sanitising path parameters, and disabling exec-related SSI directives closes most of those doors. Australian teams bound by the Privacy Act and the Australian Privacy Principles should be especially careful that fragment-level personalisation never logs identifiers in a way that survives in shared cache entries.
Caching, invalidation and TTL discipline
The Dispatcher's strength is whole-page caching, and SSI is most effective when each fragment carries its own cache lifetime. A promotional banner might cache for five minutes, a session-aware greeting for thirty seconds, and a static navigation block for an hour. Apache honours Cache-Control: max-age and Expires headers on each sub-request independently, so the outer page can sit in the Dispatcher cache while the inner blocks rotate freely underneath.
Cache invalidation in AEM normally flows through replication agents back to the Dispatcher. With SSI in play, a useful trick is to call DispatcherFlushRules on the fragment path itself, so editing one component busts only its block rather than the entire marketing page. Teams running AEM on AWS infrastructure in the ap-southeast-2 Sydney region, or peering through Melbourne data centres, often find this dramatically reduces cache-miss spikes after content updates.
Real-world use across Australian digital platforms
Australian retailers, banks and government services have long deployed AEM, and SSI fits neatly into their content delivery patterns. A Sydney-based fashion retailer, for example, can serve cached campaign pages from Melbourne or Singapore edges while keeping product availability and pricing fresh, by isolating those calls as SSI fragments. Brisbane councils and federal services like myGov use similar patterns so account-specific panels update without forcing a full page rebuild.
Local CDN choices also influence the architecture. Providers with strong Australian points of presence — including the major hyperscalers' Sydney and Melbourne regions — generally cache the outer page well, but personalised fragments still benefit from being assembled close to the user. Teams operating under the Notifiable Data Breaches scheme also weigh how cache keys handle session tokens; SSI's server-side nature means session IDs are usually invisible to the cached HTML, which simplifies compliance work. Combined with GST-aware pricing rules and AEST/AEDT-aware campaign scheduling, these regional realities shape how SSI fragments are designed.
Linking SSI to microservices and event-driven flows
SSI does not replace headless content delivery, it complements it. Many AEM shops treat the Dispatcher as the rendering tier and back it with a small services layer for inventory, pricing and authorisation. A lightweight microservices backend can publish its responses as cached fragments, which Apache then includes into the cached outer page. An architecture sketch for such a backend, including ingestion patterns and cache integration, is laid out in this microservices ingestion guide.
When a fragment needs to react to something internal to AEM — a workflow transition, a custom action, a manual publish from the author — the AEM eventing system provides the bridge. Demonstrating that pattern end-to-end is the focus of this AEM eventing walkthrough.
Tuning, debugging and operational pitfalls
Production debugging of SSI tends to surface three problems: directives that Apache silently ignores because the response MIME type was wrong, fragment paths that 404 because the Dispatcher has flushed them out of sync, and cache keys that fail to vary on headers that affect the personalised output. Apache's LogFormat can capture sub-request timings alongside the main request, which makes those issues visible without rerunning the rendering in AEM.
A common Australian gotcha is the interaction with the National Broadband Network's varied last-mile performance. A user in a regional area connecting over a satellite or fixed-wireless link sees every extra round trip; SSI's single-request assembly saves them from the multiple API calls a client-side approach would impose. Pair that with sensible fragment weight budgets — under 14 KB per include is a workable rule of thumb — and the architecture remains responsive everywhere from Sydney's CBD to a Pilbara mine site.
Background jobs also matter operationally. A scheduler refreshing cached price fragments every few minutes, for instance, leans heavily on a reliable job runner; a solid treatment of this pattern in modern .NET appears in the Quartz.NET scheduling review.
The patterns above have appeared, in various forms, at past Adobe developer gatherings and continue to shape how teams think about hybrid caching in AEM today. Practitioners who want to go deeper into these architectures and see them applied to live systems can review the upcoming programme and secure their conference seat to spend two days working through real Dispatcher and SSI configurations alongside the people running them in production.