Commerce Composer widget caching and invalidation
Site and store-level widgets can be cached for improved store performance.
- Widgets can be cached independently as fragment. This cached fragment is injected into the requested page. This type of caching allows for reuse of the widgets. For example, the header, and footer are cached separately and injected into every page request. These fragments can be invalidated independently without affecting the parent page cache entry.
- Widgets can be cached as part of ("consumed" by) the parent page. A requested page can be served fully cached. If widget contents are modified in any way, then the cached page must be invalidated completely.
Every widget has an entry in cachespec.xml. It is within this file where caching parameters are set. Not all widgets are cached, however. Whether a widget is cached, and how it is cached depends primarily on its function:
Widget content | Widget examples | Required cachespec.xml entries | Reasoning |
---|---|---|---|
Always dynamic | Inventory Availability widget | The do-not-cache and do-not-consume properties are set to true | These widgets are not cached because their content is generated in real-time based on interactions with the shopper. The content is always changing, and is never the same across different shoppers. |
Sometimes dynamic | Content
Recommendation widget Category Recommendation widget e-Marketing Spot widget |
The do-not-cache and do-not-consume
properties are set to true. The following metaDataGenerator is added:
|
Marketing widgets can contain static content, or dynamic content that is
personalized for different shoppers. Therefore, they can be consumed or cached independently based
on their individual behavior. While the do-not-cache and do-not-consume properties are required to be set to true, they can be ignored. The included metadata generator decides whether to cache the marketing widgets or not based on if the content is determined to be static or dynamic. For more information, see Overview of e-Marketing Spot JSP caching based on activity behavior. |
Static / consumable | Heading widget | The do-not-cache and do-not-consume
properties are set to true. The following special dependency ID is added:
|
Widgets with static content can be consumed by their parent pages. When a
widget is consumed, the widgets dependency IDs must be added to the parent page cache entry. These
dependency IDs cause the cached parent page to be invalidated whenever the widget contents are
modified. For this process to be achieved, any consumable widget must contain a special tag within
its JSP: When the widget JSP executes,
the associated tag handler class checks for the presence of the
ignoreDoNotConsume dependency ID. If present, the do-not-consume attribute is
reset to false, enabling the widget to be consumed by the parent page. It also
adds this widget dependency ID values to that of the parent page.
|
<cache-entry>
<class>servlet</class>
<name>/Widgets_801/com.ibm.commerce.store.widgets.Heading/Heading.jsp</name>
<property name="save-attributes">false</property>
<property name="consume-subfragments">true</property>
<property name="do-not-consume">true</property> <!-- will be reset to false, since ignoreDoNotConsume dependency-id is present -->
<property name="do-not-cache">true</property>
<cache-id>
<component id="langId" type="parameter">
<required>true</required>
</component>
</cache-id>
<dependency-id>categoryId
<component id="categoryId" type="parameter">
<required>true</required>
</component>
</dependency-id>
<dependency-id>productId
<component id="productId" type="parameter">
<required>true</required>
</component>
</dependency-id>
<dependency-id>ignoreDoNotConsume</dependency-id>
</cache-entry>