• Introduction
• Account Types
• Prerequisites
  • CDN DNS
• Workspace
• Architecture
• Extensions
• Nodes
• Layouts
  • Masters
  • Templates
  • CMS Form Tag
• Items
  • Child Items
• Draft Items
• Item Actions
• Caching
• Media Management
• Users & Groups
• Security
• Site Settings
  • Languages
  • Global Values
  • Properties
  • Data Definitions
  • User Profile
  • Membership User Profile
  • Membership Settings
  • Response Headers
  • Rewrite Directives
  • Page Redirects
  • Admin Timezone
  • Site Performance
  • Exceptions & Messages
  • MIME Types
• Tokens

Core Modules Documentation

Caching is the act of storing data in memory for ultra-fast retrieval. Caching is most beneficial for storing infrequently updated pieces of information. When the time to process a request outweighs the value of freshness in the desired output, then caching becomes an option for optimization.  The CMS framework applies this practice of caching by storing the rendered output of modules for a defined amount of time in minutes. When a Page item is configured to be cached, then the entire page is cached, including the output of all modules that may appear on the page.

When a Page is not cached but individual Modules that appear on it are, then the CMS framework will use the cached output in accordance to each module’s cache expiration.

If an item’s cache minutes is set to a value greater than 0, then an additional Cache Vary By setting is available. A module may vary its output rendering based on certain variables such as a user’s browser or a query string parameter. The CMS framework allows for the caching of multiple versions of a single item based on these variables. Below is a list of the supported vary-by types:

Type	Description	Key Example
None	Set by default.	n/a
QueryString	The query string key passed in the URL such as /catalog?ProductId=100	“ProductId”
Cookie	A cookie that exists for the requesting user.	"CookieName" or "CookieName","CookieSubValueName"
Header	A request header sent by the requesting user.	“ACCEPT-LANGUAGE”
Url	The URL of the current request.	n/a
UserAgent	The browser type of the requesting user.	n/a

When an Item is set to be cached, then upon processing by its module, the CMS framework will store the rendered output for subsequent requests. A cached item is removed or "invalidated" when an Item is published or for Page Items, when its Master or Template layout has been modified.

If a Page is set to cache, then when the Page Item is sent to the user's browser, an Expires response header is issued representing when the page expires as defined by the cache minutes setting. This informs the browser to render the local browser cache on future requests of the page until the Expires date is reached.

Pay careful consideration when setting a Page Item's cache minutes. For example, if a Page Item is set to cache for 1 day, then a response header is sent to a user's browser to also cache the content for 1 day. If the Page Item is then updated in the CMS, although the internal CMS cache is invalidated for the item, however for browser's that have been instructed to retain a cache copy, a full refresh is needed to load in the updated Page Item.

Page vs Module Cache

Every Item has it's own cache setting. However, there is a key difference in how a Page's cache setting is treated over the cache settings of other Items present on the page.

Figure 1.

In Figure 1, the Page Item is set to cache for 60 minutes while the various Items on the page have their own cache minutes set. In this scenario, even if individual Item cache expire, the overall Page Item output is rendered to the user which may contain older versions of Items on the Page. It is not until the Page cache expires are further checks made to examine the validity of cache of each Item on the page.

Figure 2.

In Figure 2, the Page Item is set to NOT cache. In this scenario, every request for this Page will return to the user the most current values. As the rendering engine encounters each Item placed on the Page, the cache is checked for a valid copy. If the cache for each Item has not expired, it is used for the rendering, otherwise, the corresponding Module is called to provide a current rendering which will put inserted into the cache for the set amount of minutes. Here, the individual cache settings on each Item on the Page are respected for every request to the overall page.

Figure 3.

In Figure 3, the Page item is set to NOT cache while a Block Item that is placed on the Page is set to cache. The Block Item contains other Items that individually have different cache settings. The concept is similar to the Page / Module cache relationship. The rendering engine will only return to the user the Block Item cache, if it exists along with the output of potentially old versions of the Items placed in the Block Item.

GET vs. POST

When a request is sent by a browser to a website, the requestor also sends information on the type of request known as a Verb. Typically, a GET verb is sent as a part of a request for a URL and lets the web server know that the user wants to retrieve output from the URL only. When submitting information to a web server such as textbox values and other HTML form inputs, the browser will send these values but instead with the POST verb. Although there are many other verbs a user can send, GET and POST are the two used most commonly.

The CMS framework takes into account the request verb when evaluating caching rules. For example, a hypothetical 3^rd party module when requested will contact an external API to retrieve information it uses to build a form that is displayed to a user. Since this particular API call can take more than 5 seconds to respond, it is logical that a CMS user wants to cache the output of this module for 1 day since the data retrieved from the API rarely changes. Under normal circumstances this is a desired behavior but because the module also accepts a user’s submission of its form, bypassing the module’s code execution and returning its cached output will not work. To solve this, the module needs to return its cached output in GET requests while being triggered to run its code in POST requests. The CMS framework implements these verb-based behavior automatically. Moreover, the CMS framework is able to intelligently determine which module should be treated with the POST verb in the event that there are multiple cached modules on a page and the user only submitted data for a single module.

Content Delivery Network (CDN)

If a CMS instance has the CDN feature enabled, then a further layer of cache is placed in front of the entire web site. To learn more about CDN DNS settings, click here. Once configured, web site visitors are directed by the DNS settings to our CDN platform. The CDN platform is composed of servers in Point of Presence (POP) that are located throughout the world. Through a networking addressing method called Anycast, the visitor will hit their geographically closest POP for cached copies of CMS pages and files. If the POP does not contain a local copy of the requested page or file, the POP will retrieve it from the CMS instance and relay it onto the visitor. Based on the Expires header that is sent in the request, the POP will then decide to store the resource in it's local cache for future requests. 

Because the CDN works off of the resource URL, the only things that can be cached by the CDN are CMS resources that can be assigned a URL. The two types of CMS resources that can be cached by the CDN are:

Name	Expiration Control
Page Items	Determined by the cache minutes setting.
Files	Determined by the Asset Expiration settings found in Site Settings > Site Performance

Note: Although service extensions can be reached by a URL, they do not emit an Expires header that the CDN uses to determine if a URL is cache-able.

Since copies of a CMS instance's content resides on geographically dispersed locations, there can be a delay in noticing content updates. The CMS framework will issue "purge requests" to the CDN platform which can up to several minutes to complete. In the case that the CMS framework cannot determine if a page or file needs to be purged, a CMS user can manually issue a purge request in Site Settings > Site Performace.