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 the Vary 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 to Edge-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-agebut it's specific to shared caches. If you have multiple CDNs, you can use the s-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 if s-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 or no-cache directives are present in the Cache-Control header, or when the private directive is present and Honor private option is enabled. The Expires header and the Default maxage setting are not honored if any of these Cache-Control directives is present: no-store, no-cache, max-age, s-maxage, privateor pre-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.