CDN Caching Deep Dive

The StackPath CDN  caches web content in locations that are geographically close to consumers of your website. Every Point of Presence (PoP) functions as a node in a global network, each storing and serving an optimized cache for local requesters of content. Cache optimization reduces unnecessary stress to your Origin and significantly improves website performance.

How Are Files Added to Cache?

Once you have completed the CDN Setup process, files on your Site will start to be cached. Here's a high-level overview of how caching occurs.

1. The user must request content from one of our PoPs. This is done by pointing users at your Edge Address or to our IP address.
2. The nearest PoP checks for the website's stored file in its cache
3. If found, the content is delivered from the CDN to the requester
4. If not found, the content is requested from the Origin server registered with StackPath
5. StackPath returns the response from your Origin to the user
6. If the file is cachable, the response is stored in the local PoP's cache

Any new content to be cached will follow steps 1-7 on the first request. Once the response is stored in the local PoP's cache, every request for the same content will terminate at Step 3.

Caching Policies

Static Files

StackPath caches your content based on the file extension and which services you have enabled. The following rules apply in most cases but are subject to vary depending on your site's particular needs.

The options bulleted below are selectable by navigating to Sites > CDN > Cache Handling > Lifetime. These options specify how long content is stored on the CDN. By default, when a new Site is created, the Cache Expiration Method will be set to Origin Controlled.

• Origin Controlled
  • Cache-Control headers on content from an Origin will determine cache expiration
  • There is no Cache-Control header associated with the content, CDN TTL defaults to max-age=3600.
• Specify CDN TTL
  • Cache-Control headers on content from an Origin will be overridden by the CDN TTL. Cache-Control headers passed from an Origin will still deliver to end-users as they appear on the origin.
• Never Expire
  • Content in cache will remain in cache until purged or removed by StackPath cache ejection policies.
• Do not cache
  • Content will not be cached.

Everything Else

Any files that don't contain file extensions that match one of the specified files above will be cached based on the max-age flag in the Cache-Control header passed by an origin. If there is no Cache-Control header returned from the origin, the CDN will apply a default max-age value of 3600.

The StackPath CDN  will also adhere to no-cache, no-store, or private flags set in the Cache-Control header on all content. These flags will prevent the CDN from caching content.

When Are Files Removed from Cache?

Once a file is stored on a StackPath PoP edge servers, the file can be removed both automatically and manually. Here are the most common ways to remove files from the StackPath cache.

Purge

When you Purge files manually from StackPath's CDN, your cached file(s) are removed from all StackPath Points of Presence(PoPs). Purging asks the CDN to obtain a fresh copy of the specified files before serving any more requests to end-users.

Purge operations can be done through the StackPath control panel or StackPath API. For more information on purging, check here.

LRU 

StackPath CDN's Least Recent Used (LRU) algorithm runs on all of StackPath's caching servers. LRU is an algorithm designed to optimize the removal of files that fall below certain end-user access thresholds. Simply put, LRU makes sure the most frequently accessed files stay in cache on a per edge basis and the least frequently used can be removed to make room for your more popular content.

The caching policy set in your StackPath control panel may be overridden by LRU on an as-needed basis. For example, if a file's caching policy is set to Never Expire, LRU will eventually remove that file unless it sees frequent usage.

How do I know if my files are cached? 

You can tell if your files are cached by viewing the X-HW header in the response headers. Headers are appended to the list chronologically, meaning the first item in the X-HW list is the first server the request interacted with. In this case, cds005.da2.hc was a load balancer and proxied the request to cds113.da2, where the asset was ultimately served from cache.

This header will resemble the following, but may vary depending on your services (i.e. HTTP vs. HTTPS delivery):

In the X-HW header, you will see the epoch time for the requests (1541178655), the server identifiers that the request goes through (cds005 and cds113), the POP that the request has gone to (da2), and the Cache code (.hc and .c). The last letter in the X-HW header will show whether a request is cached or pulled from the origin. Below are the most common cache codes you will see in requests:

Finding the X-HW Header

You can view the response headers in Chrome (Windows), Firefox (Windows), and curl (Linux and OS X/MacOS) by using the following guides.

$ curl -I https://www.example77.com/wp-content/themes/twentyseventeen/assets/js/global.js?ver=1480655561
HTTP/2 200 
date: Mon, 30 Jul 2018 19:16:51 GMT
accept-ranges: bytes
cache-control: max-age=376
content-length: 7682
content-type: application/x-javascript
last-modified: Fri, 02 Dec 2016 05:12:41 GMT
etag: W/"1e02-542a5fcbf8440"
access-control-allow-origin: *
x-cache: HIT
server: fbs
x-hw: 1532978211.cds003.da2.hn,1532978211.cds011.da2.c
vary: Accept-Encoding