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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.
recommendation-more-help
experience-cloud-kcs-help-kbarticles