From the release of 10.01.00, Miva supports native Full Page Caching via Redis. Redis is an in-memory data store used to cache any type of data. For more information about Redis visit: https://redis.io/topics/introduction
Miva's Implementation of Redis allows any page to get cached and stored in Memory for an incredible fast Time to First Byte, typically sub 200ms.
The purpose and advantage of Redis is that is reduces the number of resources the server and database is required to use to serve a page and it improves server-side rendering time, time to first byte (TTFB), which is the first instance that Miva is serving a response to the user’s request.
Using Redis to Cache pages is all about site speed and performance. It reduces the overall time the server needs to respond back with content, also known as Time to First Byte. The results of this are:
Redis needs to be enabled at the server level before you can use it. If you are unsure if Redis is enabled for your site, contact email@example.com and we can enable it for you.
Important: Redis is only available to customers on dedicated servers. (Professional Plan & Above) If you are on a shared server, Redis is not available to your site.
Once enabled you must connect your store to Redis. This is done under Store Settings -> Cache Settings.
Redis Host: Redis is typically installed on the same server as your site. So this value will almost always be 127.0.0.1
Redis Port: Redis always runs on port 6379
Redis Timeout: This is the connection timeout in the event the Redis was offline.
Redis Expiration: This is the amount of time Redis should cached each page. Default is 300 seconds or 5 minutes.
Redis Password: Optional field if your Redis setup requires a password to connect.
Cache Hits – The number and percent of successful requests which were served from Redis cache.
Cache Misses – The number of requests which were not served from Cache.
Flush Cache: This clears the cache for all pages. Note: Its not possible to clear the cache for an individual page. It's all or nothing. You also have the ability flush cache under the User Interface Branch Action Menu:
If Redis is not installed on your server, or the Host and Port are incorrect you'll see a status of "Not Connected" Message.
For every URL requested Miva generates a cache key which is a unique identifier for that page. The cache key is calculated as follows:
In addition, to the above you have the ability to adjust the cache key to include custom values such as cookies or header values or exclude URL parameters. These settings give you very granular control over when a page is cached.
Example Use Case:
Let's say you have an email campaign link with dynamic data for the parameters, so they change per customer:
Since the mc_cid is unique per customers, each of these links will have its own cache key removing all the benefit of caching the page. Using the cache rules (more below) you can setup a rule to tell Miva to ignore that URL parameter so it's not included in the cache key resulting an more customers being served the cached version of the page.
Once installed, there is a new Cache Settings Tab under Store Setting. This is where you can configure global rules for URL Parameters, Headers and Cookies which will determine if a page should be cached or not.
Name – This is the name of the Cookie, Parameter or Header you want to set the rule for. This should match the exact value of the Resource. For example, if you wanted to exclude a parameter of utm_source, this could be the name.
Type – One of three values: Cookie, Parameter or Header
Mode – One of 5 Options:
This setting allows you to exclude the page from cache, if a parameter, cookie or header contains a specific value. It's similar to "Don't Cache "Page if Present" but give you more granularity to check the value of the parameter, cookie or header.
This setting allows you to exclude the page from cache, if a parameter, cookie or header equals a specific value. It's similar to "Don't Cache "Page if Present" but give you more granularity to check the value of the parameter, cookie or header.
The following parameters are ignored from the Cache by default: gclid, utm_medium,utm_source,utm_campagin,utm_term,utm_content
In additional to the global cache settings, these settings also exist at the page level. Any value set at the page level will override that set at the global level.
There are also page specific settings which govern how a page is cached related baskets.
There are 5 Options:
The Default of all pages is "Cache Only if the basket is empty and no customer is logged in". This makes it so that its impossible to cache customer specific basket data.
Important: The Always Cache option should never be used a pages which contain shopper specific data such as a mini-cart, full basket or checkout. Always caching one of these pages would serve inaccurate information to each shopper. An example use case for this option would be a dedicated marketing landing page which never displayed any basket/shopper data.
These settings can be change individually at a per page level, or from the batch list:
There exists a function you can call from any page template TemplateManager_Page_Cache_Disable( reason ), which aborts caching of a page that would otherwise have been cached.
The Write_Basket custom field function automatically calls this new function to prevent any which writes a custom basket field from being cached.
There also exists a new function, TemplateManager_Page_Cached(), which returns 1 when a page is being rendered for caching. This function can be used in component modules so they can alter their behavior, if necessary, when a page is being rendered for the cache.
When caching is enabled, a new header named X-Miva-Cache will be output for every page hit.
When a page is cached, the header will output the text "hit" or "miss" and the MD5 component of the cache key:
X-Miva-Cache: hit 581ffcd33dbcda8cd3dd48b066dc1325
When a page is not cached, the header will output the text "off" and a reason:
X-Miva-Cache: off global-param
X-Miva-Cache: off page-header
X-Miva-Cache: off write-basket
In the event of a page hit that would otherwise be cached being invalidated due to a call to TemplateManager_Page_Cache_Disable, the reason output should be the reason will get displayed in this new header.
This header gives you visibility into why a page was not cached, or if a page was served from the cache.
For bulk importing of Cache Settings, there are XML Provisioning tags both at the store level and the page level.
Prior to Redis being built into 10.01.00, there was a stand alone module which enabled similar functionality.
As part of the 10.01.00 upgrade process any settings from the redis_page_cache_module, if installed, will get transferred into the new built in Redis Cache Settings, ensuring that the existing behavior is retained. The redis_page_cache_module will then be disabled. Both cannot be used at the same time.
All this happens automatically as part of the upgrade process.
The framework import/export process has also been updated to support saving and applying these new page specific cache settings. This allows developers to create their own frameworks with the Page level cache settings they prefer which will get automatically applied when the framework is applied.
There is logic built into the Redis Caching to prevent any template branch from ever getting Cached. This makes it so you can safely work in a template branch without having to worry about it accidently being cached and being served to customers.
You do not need to manually add the template branch cookies to the Cache settings. This happens automatically behind the scenes.
The following Runtime functions leverage redis caching to improve response times:
Since these functions are used by several flex components that are intended for placement on high traffic pages, their performance important. The intention of Redis support is to avoid as many database operations as possible, so cache lookups are performed based on input parameters prior to validation of any values, and even error responses should be cached.
The Redis Key will look like:
Where function_name is the lowercase name of the function in question.
Global store-level cache key inclusions are honored, and the following additional function-specific values are included in the cache key:
Category_ID or Category_Code
Product_ID or Product_Code
Hits and misses for runtime functions are separately tracked and displayed under the key json_cache_status:<store_id>
Below is a list of things to check when implementing Redis Caching. Server-sided logic that shows/hides content to users based on the any of the following criteria should be looked at prior to caching being enabled.
Write Basket Custom Field - When using the write_basket custom field on any page that would have been cached, there is now logic to prevent the page from being cached. If you use a write_basket custom field globally, it will prevent your pages from being cached. You'll see this response in the header: x-miva-cache: off aborted-write-basket. Its recommended these global write_basket calls get converted over into using browser session storage which will allow the pages to get cached by Miva.
Some older versions of Miva themes including Shadows and Colossus have used a global write_basket call in the global HTML Profile to save the refer URL. This will prevent the pages from being cached by Redis. The solution for this is to convert it over to Session Storage: https://github.com/mivaecommerce/readytheme-shadows/issues/64