Caching Experience Fragment Techniques in AEM Sites 6.5

This article explains different techniques to handle cache invalidation with AEM experience fragments.

• This topic will cover some of the questions that have been asked:
• What are the most efficient ways to cache AEM Experience Fragments in AEM?
• What are different ways to cache AEM Experience Fragments in AEM?
• What are the caching strategies for AEM Experience Fragments in AEM?

1. Server-Side Rendering, utilizing the out of the box (OOTB) AEM experience fragment component

Utilizing the OOTB experience fragment component, the experience fragment will be rendered and cached as a part of the HTML page.


Pros:

• Easy to include experience fragments to editable templates and pages.

Cons:

• Publishing changes for experience fragments will not automatically flush all the pages that are referencing the experience fragment.
• For large sites, flushing all pages with the experience fragment reference may cause performance issues in the live production sites.

Solution to the Cons:

• Schedule a re-activation time for the experience fragment. The time set should be when the site has the lowest traffic would be the best option.
• Create a custom replication agent to invokes all the flush agent(s) that are registered within the publish instance. Flush all the pages that reference the experience fragment; adding a minor throttling mechanism if required. The mechanism should re-fetch all pages after the flush.

2. Javascript Request and HTML Rendering
Creating a custom experience fragment component that uses javascript to request for the experience fragment HTML path. On success, inject and render the experience fragment’s HTML’s structure to the page.



Pros:

• All pages referencing the updated experience fragment will not need to be flushed.
• All pages referencing the updated experience fragments will surface new content on the page immediately.
• Flushing all pages with the updated experience fragment is not required.

Cons:

• Components defined in the experience fragment that are relying on the site’s javascript will not be working as expected.

My Solution to the Cons:

• Only allow experience fragments that do not rely on javascript to be allowed in the custom javascript experience fragment component; define the parsys that only allows specific components that do not depend on javascript like slideshows.

3. Sling Dynamic Include (SDI) Component Rendering
Sling Dynamic Include replaces specific and defined components with different types of include tags (apache include tags) and therefore allows to put dynamic content into a page cached by the dispatcher.

Configure Sling Dynamic Include on both AEM Publish and Apache Web Servers. The SDI AEM install exposes an OSGI configuration that allows you to target specific components that will be converted to SDI include tags in the publish mode. When a page is being requested from the Apache Web Server, the resolved page with the SDI includes tag will request the JCR path from the targeted components (experience fragment) and will cache the HTML in the webserver. The page with SDI includes tags will include the experience fragment HTML (cached) to the final rendered page. In summary, the render of the final page will include the experience fragment as one HTML file.



Pros:

• All pages referencing the updated experience fragment will not need to be flushed.
• All pages referencing the updated experience fragments will surface new content on the page immediately.
• Flushing all pages with the updated experience fragment is not required.

Cons:

• If an author unpublishes an experience fragment unexpectedly, the apache web server will display an error directly onto the page.

My Solution to the Cons:

• To restrict all users from unpublishing experience fragments.
• To create a custom approval workflow invoked in the “author” instance, where all pages referencing the targeted unpublished experience fragment should have the experience fragment removed, and re-published; upon approval.

Summary
In summary, for my recommendation, it really depends on the sizing, performance uptake, and business requirements of the site. If the size of the site’s content is extra-large, then the SDI and XF Javascript options would be ideal. If the size of the site is particularly small, then flush by reference would be ideal.