Confirm Experience Protection
Provide an uninterrupted experience for your users.
Experience Protection provides a seamless, uninterrupted experience for your users. Global CDN will serve a cached version of your page instead of displaying an error if the server is not responding and can't serve a new copy of the page. Global CDN will display the cached version even if it is stale cache (expired).
Confirm That Experience Protection Works
You can test how stale cache is served by comparing the header results of a page refresh when the site's Dev environment is live to the header results when Dev is in Maintenance Mode:
Examine the headers through the command line:
curl --head https://docs.pantheon.io HTTP/2 200 content-type: text/html age: 2808 cache-control: public, maxage=60 expires: Thu, 21 Sep 2023 21:39:51 GMT last-modified: Thu, 21 Sep 2023 19:04:09 GMT via: 1.1 varnish, 1.1 varnish strict-transport-security: max-age=300 date: Thu, 21 Sep 2023 21:26:39 GMT x-served-by: cache-bfi-krnt7300115-BFI, cache-bfi-krnt7300115-BFI x-cache: MISS, MISS x-cache-hits: 0, 0 x-timer: S1695331600.573858,VS0,VE60
Note the result for
age
ormax-age
.Navigate to the site's Dev environment and set the site to Maintenance Mode.
Clear the cache from either the Advanced Page Cache module or from the Dashboard.
cURL the site headers filtered for stale cache in a terminal:
curl --head https://docs.pantheon.io | grep PContext-Resp-Is-Stale
If the response headers include
PContext-Resp-Is-Stale
, the page has been successfully served from stale cache.
Navigate to the page using Firefox or Chrome, and in the browser's developer tools open the Network tab.
Find the response headers for the page or asset.
Go to the site's Dev environment and set the site to Maintenance Mode.
Clear the cache from either the Advanced Page Cache module or from the Dashboard.
Go back to the page and Developer Tools, then refresh the page for the newest header responses.
If the result includes
PContext-Resp-Is-Stale
, the page has been successfully served from stale cache.
You can check your NGINX or Fastly logs for any traffic anomalies or overages when you know what your site's cache currently looks like.
NGINX logs track all requests made to WordPress or Drupal, but do not include any requests that were served from the edge cache. You can use GoAccess to produce a compiled report on the most common requests, such as: 404s, user agents, etc.
Fastly log extracts can be requested from your Customer Success Engineer. Standard analytics include all pages requested, but will not include service calls and other traffic that does not load the tracking script.
Check your logs for:
Disproportionate patterns of requests and 404s indicate possible exploits.
Too many requests to the index paths may indicate a volumetric attack against the domain.
Heavy requests to administrative and login paths may indicate a generalized CMS exploit attempt.
Known exploit and excess traffic paths.
Adjust Max Age to Determine Fresh vs. Stale Content
Your site’s CMS page-level caching must be correctly configured to take advantage of Experience Protection.
You can adjust the length of time before the site's cached content is considered stale by adjusting the max age. Set the cache max age to a value equal to or higher than 3700 seconds for best results:
Drupal steps to change your your CDN edge settings to serve stale content for a specific amount of time.
WordPress steps to change your your CDN edge settings to serve stale content for a specific amount of time.
Session-Style Cookies or NO_CACHE
Cookies
You will bypass the cache and will not see cached content if you have session-style cookies set, or a NO_CACHE
cookie set. For best results:
- Set the
NO_CACHE
cookie to persist longer than the site’s page cache (this includes logged in users and authenticated traffic).
Learn more about the exceptions to page caching rules in Caching: Advanced Topics.