Cache variations

Refer this page to configure cache variations.
A typical use case for using this is when you would want to cache/serve different variations of responses for same URL based on some conditions.
e.g. You would want to cache your PDP pages separately, based on the currency with which the prices are shown.
Or you would want to separately cache the page shown to wordpress-admin and normal user.

Note: For demo purpose, we will be using www.nviztest.com domain as an example.
Here, we will be configuring cache variation for all the pages based on _wordpress_logged_in_ cookie.

Prerequisite

1. You must have a domain configured on Nitrogen.
2. You should have a created a cookie based condition for _wordpress_logged_in_ cookie. If not, you can refer this article for the same.

Steps

1. Click on Caching menu, then select Cache Variations tab. Select appropriate domain from the domains dropdown.
   

2. You will see a few default rules here:

   1. Vary cache based on device: cache for mobile/desktop/tablet/bot requests will be separate for same URL.
      If your site uses same HTML for all device-types, you can delete this rule.
   2. Vary cache for all query parameters: response for same URL with different query parameters will be cached separately.
      You can edit this condition to ignore specific parameters like campaign or tracking params to avoid unnecessary cache variations e.g. _utm* Refer Query parameters for it.

3. Click on Add New button at top right corner. You will be taken to a screen to provide caching details.
   Provide the required details:
   

   1. Comment: Provide short detail about the caching pattern/rule. Enter Vary wordpress admin and normal user for example.
      Note: Please keep the comment meaningful and relevant.
      

   2. When URL pattern matches: It specifies the request URL pattern condition on which the variation to be applied. You can create it using these steps.
      Select All URLs for now.
      

   3. Then: Each cached item has a unique cache-key based on method/URL/Vary-header. Here we will be providing the change for cache-key to create a variation.
      

      1. If: Here we will be specifying what to be added to cache-key when the condition matches.
         

         1. Condition Type: We can configure variation based on multiple conditions.
            e.g. URL-pattern, HTTP-method, request-header, cookie, request-user's origin-country, request-IP, request-user's device-type, request's user-agent
            Select COOKIE for now.
            

         2. Condition Value: Select the condition pattern. Here, select _wordpress_logged_in_ as per the example requirement.
            

         3. Cache Key Value: The string to be appended to cache-key when condition matches.
            Leave it empty for now. We will use the value of cookie itself.
            

         4. Use value of: When enabled, it will append the value of pattern to cache-key when condition matches.
            Enable this switch.
            

      2. Else: Here we will be specifying what to be added to cache-key when the condition does not match.
         Add value NoAdmin here.
         

      
      

   4. Click on Save button. The configured rule will be showed in Cache variations list.
      

So now, the cache variation logic will apply to All URLs.
If _wordpress_logged_in_ cookie is absent, cache-key will be appended with value NoAdmin.
If _wordpress_logged_in_ cookie is present, cache-key will be appended with the cookie value.
Thus, any cached resource will have cache variation based upon value of _wordpress_logged_in_ cookie.

Notes

1. Setting up cache variation will clear the cache of all the associated resources. Therefore, we recommend doing it in off-peak hours.

2. You should create as less cache-variations as possible in order to improve cache-HIT percentage.

3. You can also edit/remove the default cache-variations if it does not impact your application.

4. These changes will only take effect when deployed. Saving them will only be saving them in draft. Please refer documentation about Deploy process for it.

5. Refer Nitrogen response header to understand cache status of any resource.