Caching experience fragments

Experience fragments allow authors to create reusable content. Since, its availability it has been used to create headers / footers and similar reusable content.

With reusability comes the need to seamlessly update the cached pages that reference the shared content. Sharing multiple approaches for invalidation when using Experience Fragments

1. Experience Fragment (XF) html is added in pages via AEM publisher

Say you are using experience fragment on pages via OOTB Experience Fragment component. The component renders the XF html as part of pages. In such a case, the XF is cached as part of page html in dispatcher.

To update the dispatcher cache on XF updates, we could use any of the following approach:

1.1. OOTB dispatcher flush to update referencing pages

OOTB when an XF is published, AEM publish finds all pages referencing the XF. A dispatcher flush is then triggered for all identified pages.

Cons:

If XF updates are frequent and is used by many pages, then a lot of pages might be flushed frequently causing performance issues.

To avoid the default flush behavior:

1. Overlay following nodes
   • /libs/settings/updateprocessor/config/processing/xf/publish/replication
   • /libs/settings/updateprocessor/config/processing/xf/publish/entitydelete
2. Delete the child node “dispatcherflush” from each of the above.
3. Consider using TTL regular content invalidation and optimizing content refresh

1.2 Configure dispatcher to use TTL for periodic invalidation

With enabled-TTL, the pages would be invalidated at regular intervals on dispatcher. Thus, the update XF would also be available as part of them. It would optimize the content refresh

For configuring TTL on dispatcher, refer to: https://github.com/adobe/aem-dispatcher-experiments/blob/main/experiments/enableTTL/README.md

2. Using SDI for rendering Experience Fragments

Sling Dynamic Include helps to serve dynamic content. Same approach can be used for XF by caching it in “.html” format in dispatcher.

A page HTML would contain include statements, which would be processed by Dispatcher (SSI) / CDN (ESI), to render XF content. For details, please refer to https://blog.developer.adobe.com/caching-common-or-shared-content-in-aem-using-sling-dynamic-include-bd0e8b42adac . It suggests, how SDI component html and XF html can be cached separately on the dispatcher. Thus,

1. If XF is updated and published, the dispatcher cache is invalidated/deleted for the XF page
2. If a different XF/variation is updated on page and page is published, the dispatcher cache is invalidated/deleted for the page.

Note:

• If the shared content changes frequently, consider using TTL to optimize content refresh. SDI component has “component TTL” config, which allows us to invalidate the cached component periodically. We would also need to enableTTL on dispatcher. For more details, please refer to : https://experienceleague.adobe.com/docs/experience-manager-learn/foundation/development/set-up-sling-dynamic-include.html?lang=en