Caching rules

Akamai caching rules determine what gets cached and what doesn't. There are a couple of aspects to this.

Cache rules consist of a match (if the content is like this…) and an action (don’t cache or cache for this duration) and are evaluated from top to bottom. The last match that applies to a particular URL is the one used. If that doesn't result in the caching rule you want, then reorder your rules, or add a new rule at the bottom of the list to match the desired scenario.

There are two sets of cache rules. The first set is based on file extensions and the second is based on URL path matches. You can include wildcards (asterisks) in your path matches. You can include wildcards (asterisks) in your path matches, although it’s more efficient to avoid them if possible.

Caching Default Rule

Use the default rule when not applying other, more specific rules. If you don't want to cache portions of your site, it’s usually better to make the default rule "Don't cache anything except" and then apply specific rules for what you want to cache. If your site’s content is mostly cacheable, you should make the default rule "Cache everything except" and specify the content you do not want to cache.

Cache File Extensions For

The TTL length lets you adjust how long to store content with specified file extensions on Akamai servers before refreshing from your origin web server.

For dynamic content, such as images that change frequently based on your site visitors’ actions or demographics, you can set a low cache file extension. This results in refreshes that happen more often, with each refresh bringing up whatever new content may have been added since the last.

You’ll probably want a different strategy for static content, which includes such stuff as logos and identifying images, PDFs, and HTML files. You should cache this kind of content on Akamai servers and specify a longer TTL. One day is the default. Doing this should increase server offload, noticeably improving website performance and scalability.

If your content doesn’t change often, you can set your TTL to one year. The long TTL will require you to do some additional work to refresh the content if it changes in less than a year. When the content is updated, you can either purge it or update the URL with a query string that uniquely identifies the version of the content (for example, the timestamp when it was last updated). If you have a low cache hit ratio and the TTL is already long, it may be due to query strings that vary frequently or per request. In this case, update your query string logic to change only when the content changes. If it never changes based on the query string, you can enable the "Ignore query strings" setting.

Once the TTL expires, it doesn’t mean that the cached content gets deleted. It means that when a user requests the content, Akamai will need to use the If-Modified-Since HTTP header to verify with the origin server that the content is still up to date.
Important: Setting a zero (0) second TTL tells Akamai to continue storing content and revalidate it with your origin server before serving it. This behaves the same as the Cache-Control header: no-cache caching rule, but it differs from don’t cache settings (equivalent to a no-store directive), which specify to never store.

File Extensions

You should identify the file extensions that you want to associate with the chosen caching default rule. You can always modify them if you want, when you want.

Cache Path Matches

With this setting you can configure caching rules for your website’s files using a given URL path pattern. A cache path match rule specifies what order the content should be cached in, and for how long (the TTL).

To set an individual cache TTL rule for a specific file path, just enter the path and cache TTL. This setting also lets you enter a rule that will apply to multiple files in a folder.

For example, you can create the following rules in descending order in which you want them evaluated:

  • `*.gif`
  • `images/*`
  • `/images/*.gif`

In this example, if a request for the file images/sample.gif doesn’t satisfy the last cache path match, then a request for the next cache path is made. This repeats until the request is satisfied by the match.

The order of evaluation matters because more than one match could apply for the same URL. You should arrange the match rules in descending order. Generally speaking, list the more specific ones after the less specific match or wildcard rules.