Adding an ESI component within an experience fragment doesn't work

[taggatmerkle]

I have enabled ESI for a set of components, and they work fine when added to a page, however when I add the component within an experience fragment, it renders with the experience fragment instead of at edge side.

To test this I put the component both within the experience fragment and on the page itself, the version in the experience fragment was fixed and no ESI markers were part of the page cached in the dispatcher. For the component put into the page itself the markers were present.

[ShivamKumar · Accepted solution]

Hi @taggatmerkle ,

This happens because when AEM renders a page with an XF, it resolves the XF's content on the publish instance before the response reaches the dispatcher. That’s why ESI tags inside the XF are already processed (or removed) and don’t appear at the dispatcher.

However, when you place the same component directly on the page, the ESI tag is available in the response sent to the dispatcher, which then allows it to fetch the content dynamically.

For example, if your component includes an ESI tag like this:

<esi:include src="/header.html" />

And you add that component inside an XF, AEM will render it like this before it reaches the dispatcher:

<div class="header">
<!-- actual rendered HTML -->
</div>

As a result, no ESI markers are present at the dispatcher level. If you need more clarification, please let me know.

Thanks.

[SantoshSai]

Hi @taggatmerkle,

Basically, when you embed ESI-enabled components inside an Experience Fragment, AEM resolves the XF server-side - so by the time it gets to the dispatcher, it's already fully rendered. That’s why you don’t see the <esi:include> tags anymore.

When you place the same component directly on the page, AEM leaves the ESI tags intact, and the dispatcher/CDN can process them as expected.

A couple of things to consider or try:

• Avoid putting ESI components inside XFs if you need true edge-side inclusion. Wherever possible, place those components directly on the page or into templates/layouts.

• Alternative structure: In some cases, I’ve broken the XF into two parts - keep the static/shared layout in the XF, and inject the ESI components into the page or via template logic.

• Dynamic XF assembly: If this is a must-have, you might explore ways to break out parts of the XF using SDI (Sling Dynamic Includes) or design your XF to reference those components via include paths instead of static HTML.

But yeah - short version is: once it’s in an XF, AEM processes it on the publish side, so ESI doesn’t stand a chance.

hope that helps!

[taggatmerkle]

Thanks, it is a bit of a pain as I have an ESI for the navigation which has details specific to the user's access, will have to look at doing this a different way. I can't embed it into the template as the menu is different per locale