Request Caching

Refer this page to configure caching the responses. It will benefit you in improved response times, reduced load on your servers.

Note: For demo purpose, we will be using www.nviztest.com domain as an example.
Here, we will be setting 1 day caching TTL for homepage.

Prerequisite

1. You must have a domain configured on Nitrogen.
2. For this example to work, you should have created URL pattern based condition for homepage ^/(\?.*)*$. If not set, you can refer this article for the same.

Steps

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

2. You will see a few default caching rules already added there:
   Bypass non GET/HEAD requests: to not cache responses for non-GET requests.

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. Name: Provide short detail about the caching pattern/rule. Enter Homepage for example.
      Note: Please keep the comment meaningful and relevant.
      

   2. Request Condition Type: We can configure caching 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 PATTERN for now.
      

   3. PATTERN VALUE: The URL-Pattern for which this caching will be applied. Select Homepage as required for this example.
      Note: You can add multiple conditions as per your need, by clicking +Add Condition button.
      

   4. Cache Content at Nitrogen Edge Servers: Enable this switch to enable caching the responses at Nitrogen Edge CDN servers.
      

      1. Choose Status Codes: Select the HTTP status codes of the responses should be cached.
         Note: We recommend to only cache successful responses (i.e. 200). For Multimedia resources, you can also select 206.
         You can also cache error responses for short durations such as 10 minutes, till you fix the issue causing the errors.
         Select 200 for now.
         

      2. For each selected status code you will be provided the option to set the respective CDN TTL.
         

         1. TTL Unit Type: Select the caching duration unit e.g. Seconds, Minutes, Hours, Days
            Select Days as per the example requirement.
            

         2. TTL (Time To Live): Enter the caching duration you wish to set.
            Enter 1 for now, so that CDN caching for all successful responses for Homepage will be set for 1 day.
            

   5. Ignore "no-cache" from Origin: Enable this switch to override the origin's cache-control header with the one being specified at dash. If it is kept disabled, caching will be applied as per dash only when the origin does not send caching headers.
      We recommend keeping it enabled to manage caching from single place - dash.
      

   6. Cache Content in Browsers: Enable this switch to enable caching the responses at user's browsers.
      

      1. TTL Unit Type: Select the caching duration unit e.g. Seconds, Minutes, Hours, Days
         Select Days as per the example requirement.
         

      2. TTL (Time To Live): Enter the caching duration you wish to set.
         Enter 10 for now, so that Browser caching for all successful responses for Homepage will be set for 10 minutes.
         Note: Unlike CDN cache, the browser cache can only be cleared by the user. Therefore we advise to keep it minimum e.g. 10 minutes.
         

   7. Optimize browser cache: Enabling this feature will improve the browser cache by reducing the 304 status code. It will enable the browser to use the browser cache more effectively.
      

   8. Stale on error: Enabling this feature will ensure to serve a stale response(previous cached) if the backend is not healthy instead of giving an error. This helps to give a nice user experience even during the server instability. Nitrogen is configured with 4hr cache ttl for serving stale on origin error.
      

   9. Stale while revalidate: Enabling this feature instructs the caches that it may continue to serve a response after it becomes stale for up to the specified number of seconds (60 seconds), during an attempt to get the response from the origin to improve the user expericen.
      
      

   10. Click on Save button. The configured rule will be showed in Request Caching list.
       
       

Notes

1. Cache is associated with its URL. Therefore, caching the page will not cache the image/js/css resources mentioned in its HTML.

2. Caching TTL changes will apply to the matched requests only after the current cache is purged or expired.
   Cache-bypass toggle will apply immediately.

3. Any caching group when configured, will become available in purge screen to be able to purge all related items together. However, it may take up-to 5 minutes to be available in purge screen, and purge API.

4. Caching group changes will apply to the matched requests only after the current cache is expired.

5. The order of patterns is of utmost importance. The first matched rule gets applied. So, manage the order accordingly. You can use reorder for it.

6. Any rule when added, gets placed at the bottom. Use reorder to place it as per need.

7. You can se default caching rule at bottom by selecting 'Request Condition Type' as INTERNAL and value as DEFAULT. When no other caching rule matches, caching set for Default rule will be applied.

8. If no caching rule is specified, caching will be carried out based on the cache-control header received on response.

9. In case of Images, the cache TTL is managed by AIO. It overrides the values set at Dash, and sets the browser TTL to 10 minutes, and CDN TTL to 5 years which is non-editable.

10. You can verify if response is served from cache or origin by checking the value of x-cache response header.
    

    • HIT: Response is served from CDN cache.
    • MISS: Cache for response was expired/purged, and it was served from the origin.
    • NONCACHED/PASS: Response is not set to be cached, and was served from the origin.

11. You can refer cache-control response header to check the browser-cache-TTL currently set on the resource.
    CDN-cache-TTL is currently managed internally and is not available in the cache-control header. Though you can check the TTL in the Request Caching screen.

12. Caching POST calls will have very less Cache-HIT percentage for them because of their nature.

13. POST can be cached if its size is up to 8KB only. If a POST request exceeds this, it will not be cached.

14. 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.

15. Use Nitrogen debug header to identify which rule is getting applied to resource.

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

17. When configuring the caching rules, a maximum of three conditions are allowed to be added to each rule.