SiteSpect’s caching feature, currently in beta, allows your Content Delivery Network (CDN) to deliver cached web pages with testable content to your visitors. It also automates collecting Metrics on the cached pages. Testing and caching are sometimes at odds. Caching is generally reserved for static objects that do not change whereas testing introduces changes.
Benefits: Increases Speed and Reduces Bandwidth
When you cache and deliver more content from the edge, you notice a significant increase in web performance and lower bandwidth consumption. This improves the speed of your website and has a direct effect on visitor experience and business KPIs.
CDN Configuration Overview
To use this feature, your CDN must be configured in the following way:
- It must support using a cookie name as the cache key. If there is no cache key, CDN goes to SiteSpect/Origin. If SiteSpect’s RTSS header does not exist, you should not cache content.
- It has the ability to mirror caching rules on 2nd leg to 1st leg with the addition of a cache key that is a cookie.
- It must strip out Set-Cookie headers in cache.
- You must make sure Engine API calls (/__ssobj/api) always go to SiteSpect (already configured to do this).
- You must review if the CDN is changing any paths before sending the request to SiteSpect for content that we want to cache (a small number of clients do this).
Enabling the Feature
In order to enable the feature you must have admin privileges. To enable it:
- Select Manage, Configuration, Site Settings, and then select the Features tab.
- Select Enable Page Category Caching to enable the feature.
How it Works in SiteSpect
This new feature encompasses several changes that improve the cacheability of your web pages.
Cache misses occur when a CDN does not have the content in cache or if the cache key cookie has not been set yet (first hit of a SiteSpect visit). The CDN needs to be configured in advance to map the cache key cookie to certain HTML pages that are cacheable. For first hits of a SiteSpect visit, SiteSpect responds by setting the cache key cookie.
Cache Key via Cookie
CDNs often use a cache key to decide if the requested content should be pulled from the Origin or cached and delivered from cache. This feature adds a cache key cookie to the HTML request so that the CDN in front of SiteSpect can dictate caching logic.
Example of a Cache Key Cookie: ss_pagecatsearch:LcbA-1-123.234
- The first part of the cookie value is the version number stored in base64 (LcbA).
- The second part of that cookie value describes if the content is gzip compressed or not (0 meaning uncompressed and 1 meaning gzip).
- The third part of that cookie value contains all the Variation Groups (specific collection of changes or experiences in a Campaign) a visitor is assigned to sorted from lowest to highest and delimited by a period.
The following describes an example of a flow in which this new feature is active in SiteSpect and configured with the CDN:
- The CDN is configured to cache URLs that start with /categories/ with a cache cookie named CacheCategory.
- The visitor has already made an initial request and the CacheCategory cookie is set to LcbA-1-123.234.
- The visitor makes another request for /categories/shoes, which is now in the CDN cache for the CacheCategory cookie value of LcbA-1-123.234. This is a cache hit; the CDN serves the content directly to the user. The beacon call fires and sends Metrics and metadata to SiteSpect.
Page Category Caching Metrics
When you enable the feature, SiteSpect automatically creates four Metrics to measure cache hits, cache misses, totals, and ratios. These four Metrics are automatically added to Campaigns that include a cacheable Page Category:
- Edge Cache Hit
- Edge Cache Miss
- Calculation: Edge Cache Hit Total
- Calculation: Edge Cache Hit Ratio
Caching Specific Pages/Campaigns
You can control which pages are cacheable using the Cacheable checkbox on the Page Category (a collection of Triggers) page. For example, if you want to launch an A/B Campaign on your home page and search results page, create a Page Category with two URL Triggers (one for the home page and a one for the search results page) and select the Cacheable checkbox for that Page Category. When this Page Category is used in a live Campaign, requests get a cache key cookie that are passed to the CDN. The CDN also needs to be configured to know which pages are cacheable (refer to the CDN Configuration Overview).
- Edge Cache Hit – This Metric is triggered using AJAX from a cacheable page. It is also sometimes incremented during a cache miss.
- Edge Cache Miss – This Metric is triggered when a page routes through SiteSpect instead of being delivered from CDN cache.
- Calculation: Edge Cache Hit Total – Subtract cache misses from cache hits to get a total of only the hits.
- Calculation: Edge Cache Hit Ratio – Cache hits divided by ((cache hits + misses) meaning all cacheable requests).
Invalidating the Cache
When something needs to change (e.g., changing or stopping a Campaign, modifying a Page Category) you want to make sure that the visitor experience is updated by invalidating or cache busting the page. Cacheable Page Categories have versioning which is updated whenever there is a change, resulting in a new cookie value which will never exist in the CDN cache thus forcing content to be pulled from the origin. SiteSpect changes that invalidate cache include:
- A Metric in an active Campaign changes.
- A baseline Metric is activated or changed.
- Any Campaign that has a cacheable Page Category changes (meta data, Factors, Variations, Campaign Variations).
- A Site Variation changes.
- QuickChanges change.
In more detail, the beacon calls to track Metrics pass current cookies to SiteSpect and receive updated cookies in the response. A change in SiteSpect results in a new cookie value being returned in the response. So, when a cached page is requested from a CDN, the new cookie value in that request tells the CDN to not serve from cache but request a fresh/latest page from the Origin. In that request, which flows through SiteSpect, all updates/changes take effect immediately.
Conflicts and Disablements
SiteSpect detects potential conflicts and causes a disablement (stops running one of your Campaigns by setting its status to Active-Disabled). Caching testable content can cause a disablement in some scenarios in which a Campaign that doesn’t include a Page Category with caching enabled changes the page that is already cached by a different Campaign.
- Page Category 123 is created to match on list pages and is enabled for caching.
- Campaign A changes list pages and includes Page Category 123.
- Campaign B changes list pages and does not include Page Category 123.
In this scenario, SiteSpect causes a disablement as the cache key includes only Campaign A.
If the page is currently cacheable and/or it is being cached behind SiteSpect, it is likely a good candidate for caching. There are limitations with Triggers on visitor-specific data in page source or the request. For example, Triggers based on visitor behavior, geo location, and request headers such as user-agent do not work. In addition, Triggers based on page source visitor attributes (for example a data layer that indicates if a visitor is logged in or not) does not work.
During bypass, a scenario in which the CDN sends requests around SiteSpect, the Ajax calls initiated from the cached page do not route through SiteSpect and expire the cache key cookie. As a result, subsequent calls are not delivered from CDN cache since the cookie is expired. The CDN instead pulls the content from the Origin, where SiteSpect RTSS headers are not injected, and thus, the content is not cacheable.
These limitations will be reduced as this feature evolves.