Cache Settings

Caching helps your store load faster by saving previously generated pages so they can be served quickly without rebuilding them each time a visitor views them.

Cache Settings allow you to control how your store uses Redis Full Page Caching. These settings determine how URL parameters, cookies, and headers affect the cached versions of your pages.

In this guide

• How Caching Works

• Cache Keys

• Cache Rules

• Wildcard Parameter Support

Accessing Cache Settings

Access Cache Settings in the admin by navigating to: 

Path: Settings → Store Settings → Cache Settings tab

How Caching Works

A cache is a saved version of content that can be reused later. In Miva, Redis can save the fully generated HTML for a storefront page so Miva does not have to rebuild that page every time a shopper visits it.

When a Shopper visits a page:

1. Miva checks if a cached version of the page already exists.

2. If a cached version is found, it is returned immediately.

3. If no cached version exists, the page is generated normally and then stored in the cache for future requests.

This process reduces server load and improves page speed.

When product, category, or page content that uses this cache behavior is updated, Miva automatically changes the related cache key so fresh content is generated the next time that content is requested.

Cache Keys

A cache key is the identifier Miva uses to find a cached page in Redis. It works like a label for the cached content.

When a shopper goes to a page, Miva creates a cache key for that request. If Redis has a saved page with the same cache key, Miva can return the cached version. If the cache key is different, Miva generates a new version of the page.

A cache key typically includes:

• The page URL, including the domain and path
• Request parameters (GET or POST variables, such as URL query strings or form submissions)
• Selected cookies or headers, depending on your Cache Settings

When a product, category, template, or layout is updated, Miva changes the related cache key. This tells Miva to create a fresh cached version for that content, while unchanged pages can continue using their existing cached versions.

By default, request parameters are included in the cache key. Different parameter values can create different cached versions of the same page.

This often happens with tracking parameters added by ads, email campaigns, or analytics tools. These parameters identify where traffic came from, but they usually do not change the page content.

For example:

/product.html?utm_source=google
/product.html?utm_source=facebook

These URLs may create separate cached versions because the utm_source values are different, even if the product page shown to the shopper is the same.

Cache Settings allow you to control how request parameters, cookies, and headers affect caching behavior. You can choose whether they are included in the cache key, ignored, or used to prevent a page from being cached.

Cache Rules

Each rule in the Cache Settings table includes the following fields:

Name - The name of the Cookie, Parameter, or Header the rule applies to.

Type – Determines where the value comes from in the request:

• Cookie –Data stored in the visitor’s browser (such as session or tracking data)

• Parameter – Values passed in the page URL (such as query string parameters)

• Header – Information sent in the HTTP request headers by the browser or server

Mode – Defines how the value affects caching behavior. In the UI dropdown, the following options are available:

• Include in Cache Key – The value is included in the cache key, creating separate cached versions for different values

• Don’t Include in Cache Key – The value is ignored and does not affect cached versions

• Don’t Cache Page if Present – The page will not be cached if the item exists in the request

• Don’t Cache if Item Contains Value – The page will not be cached if the value contains the specified text

• Don’t Cache if Item is Equal to Value – The page will not be cached if the value exactly matches the specified value

Wildcard Parameter Support (10.13.04+)

The Name field in Cache Rules supports wildcard matching for Parameter types. A trailing asterisk (*) can be used to match multiple parameters that share the same prefix.

Example: utm_*

This rule will match any parameter beginning with utm_, including:

• utm_source

• utm_campaign

• utm_medium

• utm_term

• utm_content

For example, the following URLs may contain tracking parameters:

/product.html?utm_source=google
/category.html?utm_campaign=spring-sale
/index.html?utm_medium=email

In a URL parameter, the text before the = is the parameter name and the text after it is the value. For example, in utm_source=google, the parameter name is utm_source and the value is google , indicating that the visitor came from Google.

Using a wildcard allows a single rule to apply to groups of related parameters instead of adding each parameter individually. Without this rule, each parameter variation could create a separate cache key for the same page.

Learn More

For full details on configuring Redis caching, including cache keys, page-level settings, and advanced configuration, see: Redis Full Page Caching Documentation