AEM solution for ESI personalization caching with client-side rendered components
Personalized content may not behave as expected when Edge Side Includes (ESI) is used with components that are rendered on the client instead of returned as server-rendered HTML fragments. Aligning the implementation with server-rendered fragment endpoints for ESI use cases, or using a client-side approach for components that remain client-rendered, can help resolve the issue.
Description description
Environment
Adobe Experience Manager as a Cloud Service
Issue/Symptoms
- After implementing ESI for personalized content on Adobe Experience Manager as a Cloud Service publish pages, users may see unexpected caching behavior.
- If an anonymous user warms the cache for a public page, an authenticated user may later see the anonymous version of a personalized component, or the reverse may occur.
- Affected components can include items such as headers, subscription areas, or other page elements expected to vary by user context.
- No clear error message may appear in logs or in the browser, even though the personalized output doesn’t render as expected.
- You can confirm the issue by comparing the same page in anonymous and authenticated sessions after cache warm-up and checking whether the affected component is returned as server-rendered HTML in the origin response or rendered later by client-side JavaScript.
Resolution resolution
Try the following steps to solve the issue:
-
Check whether the component used for personalization is returned from the origin as a server-rendered HTML fragment or rendered later in the browser by JavaScript.
-
If you need ESI to assemble personalized content, expose the relevant component as a server-rendered HTML fragment that can be included separately. Update your ESI or Apache Sling Dynamic Include configuration so that it references the server-rendered fragment endpoint.
-
If a component must remain client-side rendered, use a client-side personalization pattern for that component instead of relying on ESI to assemble it.
-
Validate the updated implementation.
- Test the page in both anonymous and authenticated sessions.
- Confirm that each session receives the expected version of the affected component after cache warm-up.
- Verify that the origin response contains the expected fragment output for components intended to be handled by ESI.