July 1st 2024
When building a new Storefront, Performance is one of the most important aspects you need to be mindful of.
In one of my recent projects mentioned in this Blog, using Sitecore XM and OrderCloud, we noticed some slowness in our Product Details Page, when we put it under Load Testing.
Although OrderCloud is a very fast and scalable SaaS API, we needed many API Calls to fully implement our PDP, in addition to an internal API call to get some Back-Office Data:
Get Product
Get other products from same family (Parent/Child assignments: Link)
Get Related Products (Set up in a Product's XP)
Get Product Assigned Categories
Get Product Assigned Inventory based on User Group
Additional Call to internal Back-Office API
As you can see, that makes for a lot of calls to build PDP. Some other areas of the storefront also make many calls to get product data.
During load testing we clearly noticed significant performance drops in these areas.
So we needed to implement caching to avoid that many calls to the APIs.
We needed a Caching strategy that meets the following requirements:
Reliable: Shows up to date information at all times
Distributed: Shows same data across different CD instances
Accessible: Easy to manage and Clear if needed without restarting the CDs
Redis was the obvious choice, especially since it comes with Sitecore Install on PaaS out of the box.
We identified 2 structures for our products, used in different areas of the Storefront:
Product Details: Includes all the data needed for PDP and listed above
Product Summary: Includes some of the data listed above and involves fewer API Calls.
We needed to cache both structures and have them language versioned as well to display the right currency, price and so on, based on Geo-Location.
We used the following unique cache keys:
{productId}_details_{Sitecore.Context.Language.Name}
{productId}_summary_{Sitecore.Context.Language.Name}
For this to work properly, we needed a mechanism to ensure Data is always up to date. That's where OrderCloud Webhooks come handy.
Whenever a product or related data gets updated, you need to remove the product from cache, for all supported language versions. So the next calls picks up the updated product data and pushes it to Cache again.
This diagram presents how and where product data is flowing from to the Storefront (PDP example):
It's important to identify all the Endpoints that impact the product data based on your situation and use them as Routes/Triggers for your Webhook.
In our case, this means the following routes:
This implementation was a game changer for us, as it exponentially improved our Storefront server-side performance, allowing us to reach a 99% Lighthouse Score.
We implemented Redis Caching for other scenarios as well.
If you're on Sitecore XM/XP on .NET MVC, I'm sharing this Github Repo with a Redis Cache Manager you can add and use/adapt in your solution.
P.S: This implementation was build on a Sitecore XM 10.3 Solution with OrderCloud and Azure Redis.
I hope you find this post helpful. Feel free to reach out if you have any questions or comments.
Comments