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.
- 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.
- The nearest PoP checks for the website's stored file in its cache
- If found, the content is delivered from the CDN to the requester
- If not found, the content is requested from the Origin server registered with StackPath
- StackPath returns the response from your Origin to the user
- 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.
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.
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
privateflags set in the
Cache-Controlheader 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.
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.
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:
|c||Indicates the request was served from cache.|
|e||Indicates the request was expired and the edge server did a conditional (If-Modified-Since) request to the origin, which resulted in a new version of the file being proxied from the caching server.|
|h2||Indicates the request was proxied by H2Proxy, and it's either an HTTP 1.x request, or a HTTP 2 clear text request.|
|hc||Indicates the HTTPS request was proxied by H2Proxy, and H2Proxy did a session-reuse handshake.|
|hn||Indicates the HTTPS request was proxied by H2Proxy, and H2Proxy did a full handshake.|
|p||Indicates the request was proxied from the origin. This should only be used by the edge server when it pulled the file directly from the origin.|
|pc||Indicates part of the requested content is in cache. The remainder required an origin pull. Applicable to segmented assets only.|
|pr||Indicates the request was expired and the edge server did a conditional (If-Modified-Since) request to the origin. The cached asset was updated with new expiration time only and file is served from cache.|
|s||Indicates the request was proxied from a shield edge server.|
|sr||Indicates the request was expired and the edge server did a conditional (If-Modified-Since) request to the shield. The cached asset was updated with new expiration time only and file is served from cache|
|sc||Indicates the request was for a no-cache/no-store asset and the edge pass thru the request header to the origin. This may not be a conditional (If-Modified-Since) request if the asset is a no-store asset.|
|x||Indicates the request was expired but served from cache.|
|sl||Indicates the request was served by Serverless Scripting.|
|wx||Indicates the request was scanned by the WAF, this will only happen on requests that proxy to the origin when WAF is enabled.|
Indicates the SSL Handsake is done on the box and the session was reused from a previously cached one.
|shn||Indicates the SSL Handsake is done on the box and the session is a new session.|
|t||Indicates the request was handed off through our load balancer to an edge server.|
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.
- Open the Inspector/Press F12
- Go to the Network tab
- Optional: at the bottom of the Network tab, there's an icon that's a solid black circle. When you hover over it, the tooltip is "Preserve Log upon Navigation" If you click that button, it turns red ("recording") and then it won't clear the history when you navigate between pages so you get a full trace
- Select the URL of the item you want to inspect. Find Response Headers
If you do not see anything in the URL section, try refreshing the page
- Press F12
- Go to the Net tab
- Select the URL of the item you want to inspect. Find Response Headers.
If you do not see anything in the URL section, try refreshing the page
1. Open Terminal
2. Type: curl -I www.website.com/path/to/file
Cache Hit Ratio
You can view your cache hit ratio by selecting a site and then browsing to Sites > Analytics > CDN > scroll down to Cache Hit Ratio.
Caching statistics are highly variable between websites, entirely dependent on the amount and type of content being served. We suggest obtaining a baseline cache hit ratio and compare scores relative to that to determine changes in performance. The baseline miss ratio should be drawn over a long enough period of time to include expected traffic levels and numerous cycles of purges. Usually, this is at least a week.
Determine a baseline for your website, this should reflect the Transfer Hit Ratio and Request Hit Ratio of your site in healthy condition. For most sites an 80% to 90% Cache Hit Ratio is excellent. Divergence from the baseline could indicate an issue with the CDN or your server.
- Transfer Speed - Total amount of bandwidth per second, cache and uncached, that passes through the CDN
- Request rate - Number of requests per second, cache and uncached, that pass through the CDN
If you have any additional questions, please email us at email@example.com.