Caching
Set this behavior to cache content on Akamai platform servers and associate caching instructions with content sent downstream to browsers or mobile devices.
If your origin server's response includes the
Vary
header, Akamai edge servers may ignore caching rules and the content won't be cached. See the Remove Vary Header behavior for more details on how theVary
header affects cacheability.
How it works
Default settings apply to all objects under your property configuration. For example, the caching setting tells the edge servers to cache content for an infinite time and remove the least recently used objects (LRU) to make room for new ones and free capacity. Using this behavior, you can modify the default values or create more complex caching instructions.
Default settings and available caching features may depend upon your contract. For example, the defaults for site performance are different from HD delivery.
For a detailed overview of Akamai platform caching, tips and best practices, see Learn about caching.
Additionally, you might want to check the Tiered Distribution behavior that fetches content from other Akamai servers that request content from the origin only when necessary. This decreases the load on the origin and reduces the time it takes to retrieve content.
Caching options
Cache
Select this option to cache content in Akamai platform servers for the time you specify in the Maxage field. Once cached, edge servers calculate the remaining time to live (TTL) in cache for the object. Setting a positive time, you can choose units of seconds, minutes, hours, or days.
If you set Maxage to 0, edge servers cache the content and revalidate it with the origin for every request - similar to how Cache-Control: no-cache
works with browser caches.
In the Force revalidation of stale objects field, specify what to do when an object's caching life has expired. Edge servers can either serve the object only if it has been re-fetched or validated at the origin, or serve stale, which is useful when the origin is not available. After serving the stale object, the TTL timer is reset.
No store
Select this option to serve the content from the origin and clear any versions from the edge cache. Additionally, with the Downstream Cacheability behavior set to Don't allow caching, No store option disables downstream caches, so that you can configure edge servers to send these cache-busting headers downstream to the clients:
Expires: <current_time>
Cache-Control: max-age=0
Cache-Control: no-store
Pragma: no-cache
Bypass cache
Select this option to serve the content from the origin without removing any cached versions from edge servers. Bypass cache also disables downstream caches.
You might want to bypass cache for the client requests when using central authorization. If the user authenticates, you can redirect them to the cached content. Otherwise, edge servers return a login module.
You can turn off Bypass cache for particular content by setting the response header at the origin to
Edge-Control: !bypass-cache
.
Honor origin Cache-Control and Expires
Select this option to configure content caching through honoring the Cache-Control
and Expires
response headers from the origin.
For Honor origin Cache-Control and Honor Cache-Control and Expires options, if the Cache-Control
header contains the must-revalidate
or proxy-revalidate
directives, edge servers ignore the Force revalidation of stale objects setting and don't serve stale content unless validated with the origin server. If the must-revalidate
or proxy-revalidate
directives are not present in the Cache-Control
header, in the Force revalidation of stale objects field, specify what to do when an object's caching life has expired. Edge servers can either serve the object only if it has been re-fetched or validated at the origin, or serve stale, which is useful when the origin is not available. After serving the stale object, the TTL timer is reset.
Set the Default maxage edge servers can use in case the relevant origin header is not found or is invalid. Default maxage is ignored if another honored directive that affects TTL is used by the origin.
You can enable Enhanced RFC support that lets you honor additional Cache-Control header directives from the origin. The directives adhere to RFC-standards, except for the no-transform
one, which is disabled by default. The directives are grouped by functionality.
Turning on Enhanced RFC support for an existing property may change the way your traffic is cached. Test your configuration in the staging environment to ensure that caching works as you expect.
Cacheability settings
Cacheability settings determine whether or not to cache the content.
-
Honor no-store: When the
no-store
directive is set on the origin, edge servers don't cache the response. Depending on how you configure the Downstream cacheability behavior, edge servers may send cache-busting headers to prohibit downstream caching.You can turn off
no-store
for particular content by setting the response header at the origin toEdge-Control: !no-store
. -
Honor private: When the
private
directive is set on the origin, edge servers don't cache the response. With Enhanced RFC support disabled, cache-busting headers are sent to prohibit downstream caching. -
Honor no-cache: When the
no-cache
directive is set on the origin, edge servers cache and validate or refetch content for each request.If you disable Enhanced RFC support, and the
no-cache
directive is present, edge servers don't cache the response.
Expiration (TTL) settings
Expiration settings determine how long to cache the content.
-
Honor max-age: Edge servers will cache the object for this set length of time. This setting takes precedence over the value you set in the Default maxage field.
-
Honor s-maxage: Similar to
max-age
but it's specific to shared caches. If you have multiple CDNs, you can use thes-maxage
directive across all of them. Edge servers will cache the object for this set length of time. This setting takes precedence over the values you set in the Default maxage field or Honor max-age directive. Stale objects are not served ifs-maxage
is present.
Revalidation settings
Revalidation settings determine how edge servers handle the stale content.
-
Honor must-revalidate: Edge servers won't use stale objects for new requests unless successfully validated with the origin.
-
Honor proxy-revalidate: Edge servers won't use stale objects for new requests unless successfully validated with the origin.
Akamai servers don't cache objects when the
no-store
orno-cache
directives are present in theCache-Control
header, or when theprivate
directive is present and Honor private option is enabled. TheExpires
header and the Default maxage setting are not honored if any of theseCache-Control
directives is present:no-store
,no-cache
,max-age
,s-maxage
,private
orpre-check
.
Honor origin Cache-Control
Select this option to configure content caching through honoring the Cache-Control
response header from the origin.
All behavior options work the same way as for Honor origin Cache-Control and Expires.
Honor origin Expires
Select this option to configure content caching through honoring the Expires
response header from the origin.
In the Force revalidation of stale objects field, specify what to do when an object's caching life has expired. Edge servers can either serve the object only if it has been re-fetched or validated at the origin, or serve stale, which is useful when the origin is not available. After serving the stale object, the TTL timer is reset.
Set the Default maxage edge servers can use in case the relevant origin header is not found or is invalid. Default maxage is ignored if another honored directive that affects TTL is used by the origin.
Expiration precedence
When you select Honor origin Cache-Control or Honor origin Cache-Control and Expires as your caching option, origin caching headers take precedence over property configuration settings, and the Cache-Control
header overrides the Expires
header.
The precedence is affected by the Enhanced RFC support in the following ways:
-
With Enhanced RFC support disabled, the settings that determine when cached objects expire include, in order of precedence:
max-age
,pre-check
, and the Default maxage setting.If the
Expires
header is present, it takes precedence over the Default maxage setting. -
With Enhanced RFC support enabled,the settings that determine when cached objects expire include, in order of precedence:
no-cache
,s-maxage
(with Honor s-maxage enabled),max-age
(with Honor max-age enabled),pre-check
, and the Default maxage setting.
The No store and Bypass cache options can't be overridden by any other caching settings. To override these options, you must turn them off, for example, by using Edge-Control
response headers.
Note also that settings from certain requests - for example, cache instructions sent with ESI <include>
requests override origin headers and configuration settings, other than no-store
or bypass-cache
.
If you have multiple instances of the Caching behavior in your property, for example, you configure another Caching behavior in a nested rule, the last occurring instance of the behavior takes precedence.
Related topics
See What you need to know about caching, Cache Prefresh/Refresh, Downstream Cacheability, Tiered Distribution.
Updated 3 months ago