Caching Testable Content Using a CDN

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:

  1. Select ManageConfigurationSite Settings, and then select the Features tab.
  2. Select Enable Page Category Caching to enable the feature.

How it Works in SiteSpect

This feature improves cacheability of selected HTML pages via Page Categories and cache key cookies. It also uses beacon/JavaScript calls to track SiteSpect Metrics and update SiteSpect cookies on cached HTML pages to invalidate the cache when changes occur.

Definitions

This new feature encompasses several changes that improve the cacheability of your web pages.

Cache Misses

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 Hits

Cache hits occur when a CDN has the requested content in its cache. The CDN serves the content from cache with additional JavaScript code that tracks Metrics using asynchronous beacon calls. These calls can update the cache key cookie (expiration time and assignment if necessary).

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.

As a result, the first request of every new visit is required to go to SiteSpect. In these requests, SiteSpect assignment occurs, cookies are set, and the page is injected with code to track Metrics using beacon/JavaScript calls. This is where the cache key cookie is set, with expiration generally set to 30 minutes (based on User Session Timeout setting in SiteSpect). Expiration indicates the start of a new visit during which a request must go to SiteSpect.

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:

  1. The CDN is configured to cache URLs that start with /categories/ with a cache cookie named CacheCategory.
  2. The visitor has already made an initial request and the CacheCategory cookie is set to LcbA-1-123.234.
  3. The visitor requests /categories/shoes, which is not in the CDN cache for the CacheCategory cookie value of LcbA-1-123.234. This is a cache miss; the CDN routes the request through SiteSpect. Before sending the response, SiteSpect injects JavaScript code to make a beacon call back to SiteSpect which will be used to track Metrics and other metadata. The beacon call routes through SiteSpect and fires in case of a cache miss.
  4. 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).

Tracking Metrics

HTML pages that are cached and delivered from the CDN contain asynchronous beacon/JavaScript calls to track Metrics, update visit/counted state, and update SiteSpect cookies (including the cache key cookies in case a SiteSpect change requires cache invalidation).

By default, these Ajax calls fire on DOMContentLoaded but you can modify the event using the Cacheable JavaScript Event field when you select ManageConfigurationSite SettingsFeatures. There you can provide a different event such as"load" if you want to fire these calls after the page is loaded. In order to keep visit data accurate, this event must fire once per page load.

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

For example:

  1. Page Category 123 is created to match on list pages and is enabled for caching.
  2. Campaign A changes list pages and includes Page Category 123.
  3. 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.

Limitations

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.