Before launching a high-traffic marketing campaign, take a few minutes to review your Redis caching setup. Email, ad, SMS, and analytics tools often add tracking parameters to storefront URLs. If those parameters aren’t handled correctly, Miva may create multiple cached versions of the same page, reducing cache efficiency when traffic increases.
Review Tracking Parameters in Cache Settings
Before sending an email, ad, SMS, or other marketing campaign, review the query string parameters used in your campaign URLs and compare them with the store’s Cache Settings.
Marketing and analytics platforms often add tracking parameters to URLs to identify where traffic came from. These parameters typically do not change the content displayed on the page. If they are included in the cache key, however, each variation can create a separate cached response for what is otherwise the same page.
These URLs point to the same product page but use different utm_source values:
/product.html?utm_source=email/product.html?utm_source=facebook
If utm_source is included in the cache key, Miva may create a separate cached version for each URL. Setting it to Don’t Include in Cache Key allows both requests to use the same cached response.
Common tracking parameters that can be excluded from the cache key include:
attn_poscampaignidfbclidgad_*gbraidgclidgtm_*scidsrsltidtrk_*ttclidutm_*
Note: utm_* is a wildcard rule that matches parameters beginning with utm_, such as utm_source, utm_medium, and utm_campaign.
Configure each parameter:
1. Go to Store Settings → Cache Settings.
2. Add the parameter to the cache settings.
3. Set Type to Parameter.
4. Set Mode to Don’t Include in Cache Key.
5. Save your changes.
Only exclude parameters that do not affect the content returned by the page. If a parameter changes what shoppers see, it should not be ignored in the cache key and may require a different cache setting.
Temporarily Increase Redis Expiration
Redis Expiration controls how long a cached response remains in Redis before it expires. The value is configured in seconds, and the default is 300 seconds (5 minutes).
Before a planned traffic spike, consider temporarily increasing the Redis Expiration value. A longer expiration allows cached responses to remain available longer, reducing how often Miva needs to regenerate them while campaign traffic is high.
After the campaign ends, return Redis Expiration to the store’s normal value if the temporary increase is no longer needed.
To review or change Redis Expiration, go to:
Store Settings → Store Details → Cache Configuration
Prewarm Important Pages
Cache prewarming means loading important storefront pages before a campaign begins so Miva can generate and store their responses in Redis. This helps reduce the amount of page generation Miva needs to perform when a large number of shoppers arrive at the same time.
Before a major campaign, prewarm the pages most likely to receive traffic, such as:
- Campaign landing pages
- Storefront page
- Featured product pages
- Featured category pages
- Pages linked directly from email, ads, SMS, or social campaigns
To prewarm a page, open the page in your browser. The first request may return a miss while Miva generates and stores the response in Redis. Reload the same URL and confirm that the X-Miva-Cache response header returns hit.
Confirm Pages Are Caching
Use your browser’s Developer Tools to confirm that important campaign pages are being served from Redis cache.
In Chrome, you can open Developer Tools a few different ways:
-
Windows/Linux: press
Ctrl + Shift + I -
Mac: press
Command + Option + I - Or right-click anywhere on the page and choose Inspect
Once Developer Tools is open, follow these steps to check the X-Miva-Cache header:
1. Open the storefront page you want to test.
2. Open Developer Tools.
3. Click the Network tab.
4. Reload the page.
5. In the list of requests, click the main page request. It is usually the first request and often has a Type of document.
6. In the panel that opens, click Headers.
7. Scroll to Response Headers.
8. Look for the X-Miva-Cache header.
The X-Miva-Cache header tells you how Miva handled the request:
X-Miva-Cache: hit <hash>— Miva served the response from Redis cache.X-Miva-Cache: miss <hash>— No matching cached response was available, so Miva generated the response.X-Miva-Cache: off <reason>— The response was not cached. The value afteroffindicates why the response was not cached.
A successful cache hit appears in the response header like this:
X-Miva-Cache: hit 581ffcd33dbcda8cd3dd48b066dc1325
The value after hit or miss is expected and represents the MD5 component of the cache key.
A miss on the first request can be normal. Reload the same URL and check the header again. If the page is cacheable, the next request should usually return:
X-Miva-Cache: hit <hash>
If you see X-Miva-Cache: off <reason>, use the reason to determine why the response is not being cached. For example, aborted-write-basket indicates that a basket write prevented caching.
write_basket
Before a major campaign, confirm that important campaign pages are not being prevented from caching by write_basket.
If a page returns X-Miva-Cache: off aborted-write-basket, a write_basket custom field is preventing that response from being cached.
If write_basket is used globally, such as in the global HTML profile, it can prevent caching across the storefront.