Personalization and Performance What personalized content on AEM and Magnolia costs in cache hits and load time, and how to keep that cost in check
Personalization shows different visitors different content, so one URL has several valid responses. Either the cache stores each variant separately, or it is bypassed, or the variant is only assembled in the browser. Each path has a price that shows up in Time to First Byte or in Largest Contentful Paint.
In the Core Web Vitals Benchmark 2026, server response time is already too high for 80.3 percent of AEM websites and 78.8 percent of Magnolia websites whose main content loads too slowly. Personalization that routes pages around the cache makes exactly this bottleneck worse.
Personalization in the cache: every variant is a separate entry
Personalization adds an attribute to the cache key, such as segment, region or device. The number of entries grows with the product of the variants: two personalized components with three variants each result in up to nine versions of the same page, each with its own first request.
- AEM Dispatcher: a single personalized component is enough to exclude an entire page from the cache (AEM Dispatcher Cache).
- Magnolia: in the default configuration, Magnolia does not cache pages with personalized content at all (Magnolia Cache).
- CDN: without dedicated rules, a CDN serves the first stored response to everyone. Personalized pages are therefore often excluded from the CDN altogether.
Client-side personalization with Adobe Target: pre-hiding delays Largest Contentful Paint
On the client side, the cache delivers a uniform page and a script swaps content in the browser. The hit ratio stays high; the cost moves into rendering. To keep the default content from flashing up, Adobe Target hides the page until its response arrives:
- at.js: the pre-hiding snippet sets
body {opacity: 0 !important}and removes the style on response, on error or when its timer expires, by default after 3,000 milliseconds (Adobe: Manage flicker with at.js). - Web SDK: the Platform Web SDK uses its own snippet with the ID
alloy-prehiding, also set to 3,000 milliseconds in the example. Adobe recommends hiding only the containers with personalized content instead of the whole body (Adobe: Manage flicker with Web SDK).
Elements with an opacity of zero do not count as LCP element (web.dev). Largest Contentful Paint therefore lands no earlier than the end of the hiding. Without hiding, the page flickers, a swapped hero image becomes a new, later LCP element, and the swap can raise Cumulative Layout Shift.
On AEM pages, the setting Use accurate targeting, active by default, makes delivery wait for the context to load (Adobe). With Edge Delivery Services, the Target call runs in the first loading phase and, according to Adobe, directly affects LCP (aem.live). Tags and testing tools as a whole are covered in Third-Party Scripts.
Server-side and hybrid personalization: the decision before the first byte
When the decision is made on the server or in the CDN, the right version reaches the browser complete, with no hiding and no flicker. Google therefore recommends server-side testing wherever feasible (Chrome for Developers). Adobe Target offers the Delivery API and server SDKs for this. In the hybrid model, the server decides on the first view and the browser script applies the result; in the Web SDK, the applyResponse command has served this purpose since version 2.13.0 (Adobe: Hybrid personalization).
The price moves into response time: the server waits for the decision, and the page is no longer cached as a whole. Most economical is a cached page with only individual components generated per visitor.
| Approach | Cache | Load time | Control variable |
|---|---|---|---|
| Client-side with pre-hiding | uniform page in cache | LCP no earlier than end of hiding | hidden area and timeout |
| Client-side without pre-hiding | uniform page in cache | flicker, later LCP element, layout shift | reserved space per component |
| Page variants in cache | one entry per variant combination | fast on hit, slow on every first request | number of active variants |
| Components via include | page cached, component separate | response time of the component is added | number and duration of includes |
AEM: Sling Dynamic Include keeps the page in the Dispatcher cache
Sling Dynamic Include replaces a personalized component in the cached HTML with a placeholder that the web server fills via Server Side Include, a CDN via Edge Side Include or the browser via JavaScript (Adobe). On AEM as a Cloud Service, the bundled Fastly-based CDN currently does not support Edge Side Include, while Server Side Include via mod_include in the Dispatcher works (Adobe KA-21610).
AEM's own personalization relies on ContextHub, whose stores live in the browser and whose segments are resolved there via JavaScript (Adobe: ContextHub). Experience Fragments can be exported to Adobe Target as offers (Adobe). Both paths are client-side and follow the same rules for hiding and reserved space.
Magnolia: segments, Advanced Cache for Personalization and variants in the CDN
Magnolia assigns visitors to segments via traits and serves variants of pages or components per segment. With the Advanced Cache for Personalization module from DX Core, each combination of requested variants becomes its own cache entry (Magnolia), and every additional segment lowers the hit ratio. The dynamic page caching module caches the page and renders only the dynamic components per request.
For Magnolia DX Cloud with Fastly, Magnolia describes how the CDN separates variants: traits are read from the request, normalized into a few categories and added to the cache key via the Vary header. Device type, region and segments with few values are suitable, for example three to five device types; cookie-based traits usually have too many values (Magnolia: Personalize content with CDN caching).
Variant budget, RUM measurement and sign-off: personalization as a managed metric
- Limit per page type: a maximum number of simultaneously active variants or segments, recorded in the performance budget.
- Separate measurement: in Real User Monitoring, every measurement carries the attribute personalized or not personalized, plus the activity. Only then does the gap at the 75th percentile of LCP become visible.
- Timeout rate: Adobe describes reaching the timeout as a rare case. Its actual frequency belongs in the analysis per page type.
- Sign-off: every new activity names page type, variants and hidden area, reserves space at a fixed height and keeps the LCP gap below an agreed target value.
How such requirements are written as tickets is shown in the Core Web Vitals acceptance criteria.
Book a free performance analysis
30 minutes via video call. You see what share of your main content's load time goes to personalization and testing tools.
Frequently asked questions about personalization and performance
Does Adobe Target worsen Largest Contentful Paint?
Used client-side, usually yes, because the pre-hiding snippet hides the page or parts of it until Target responds. Hidden elements do not count as LCP element, so the value lands no earlier than the end of the hiding. The size of the gap shows in Real User Monitoring that separates personalized and non-personalized page views.
How many personalization variants can a cache handle?
There is no universal figure, because every combination of variants is its own entry and the hit ratio also depends on traffic and publishing frequency. For separation in the CDN, Magnolia names a few categories per trait, for example three to five device types. A limit per page type in the performance budget, derived from the measured hit ratio, makes sense.
Is server-side personalization always faster?
No. It avoids hiding and flicker but moves the waiting time into server response time. If entire pages bypass the cache as a result, Time to First Byte rises. The most economical setup is a cached page with individual components generated per visitor via include or in the CDN.
How can the impact of personalization be measured?
In Real User Monitoring, with an attribute per measurement indicating whether the page view was personalized, plus activity and page type. The comparison uses the 75th percentile of LCP for both groups. Pre-hiding timeout rate and the cache hit ratio of personalized page types complete the analysis.