To make use of Accelerated Domains, you need headers set in the application to let the Accelerated Domains cache engine know what to cache and not, and the Cache TTL (time-to-live).
String value with the cms name, for controlling cms specific features in Accelerated Domains. Please note that this header might not be visible as response headers by the requesting client.
Accelerated Domains supports a set of various cache controling headers. These are read in a prioritized order:
We highly recommend setting the CDN specific
CDN-Cache-Control header. Accelerated Domains reads the CDN-Cache-Control header first, and it has the highest priority. If the CDN-Cache-Control header is set, the other cache controling headers are not read or respected.
We highly recommend setting a cache control header on HTML responses. Specifically setting max-age (cache TTL for private caches, i.e browser cache). If this is not set, we set the value in Accelerated Domains when we read the HTTP headers sent by the origin.
s-maxage (cache TTL for shared caches) is not required, as this will be overwritten by the x-acd-ttl value, but we recommend setting the value to 600 (10 minutes) in case there are scenarios with shared caches between Accelerated Domains and the origin.
On pages that should not be cached, both max-age and s-maxage should be set to 0.
Accelerated Domains alters and sets it's own
Cache-Control headers, so to be able to see the
Cache-Control header sent by the origin we move the value of the
Cache-Control header sent by the origin to a new header named
Origin-Cache-Control for easier debugging.
Integer value for how many seconds the content should be cached by Accelerated Domains. Can also be string no-cache if the response should not be cached. Recommended value on cachable pages: 86000 (24 hours – 400 seconds)
x-acd-status is present if the requests has gone through our Accelerated Domains HTML optimization worker. The status header can have multiple values, and also provides minimal debugging information.
|Cache is hit, and response is served from cache.|
|Cache is bypassed.|
|Cache is hit, and response is served from cache. However, the request will not be stored in cache. Reason is that the request, if it hits origin, might respond with a non-unique response (i.e cart content in header carts etc).Reason for no-store is also present. Currently will always be cookie as this is the only thing that trigger a no-store.Happens if woocommercecart* cookie is present, but the request can be served from cache.|
|Worker is bypassed. Reason is included.|
|Cache is missed. The request should fill the cache, and the next request should be a HIT.|
|The plugin does not seem to be installed or/and we do not get the correct headers.|
A reason for the behaviour might be sent through the
x-acd-status header. These reasons includes:
|cookie||The request has a cookie present that is in our list of cookies that should trigger a bypass. i.e nocache or wordpress_logged_in*|
|url||The request is to a url which is set to be bypassed in our worker. i.e cart or checkout.|
|set-cookie||The response from server includes a set-cookie header, making the response unique and therefore impossible to cache safely.|
|private||The response from server includes a cache-control header which sets the response as private. A private response cannot be cached.|