One of the core benefits of Akamai CDN is the ability to retrieve content from origin servers and cache it in Akamai servers at the edge of the Internet, near end-users. This feature improves performance by reducing the load on the origin server and reducing the time required to serve content to end-users.
Property Manager automatically assigns a caching setting to your content. By default, edge servers cache content for a theoretically infinite time. Objects are removed from cache on a least recently used (LRU) basis. If a server is retrieving new content for an already full cache, one or more object(s) may be removed from cache if not requested in as little as as a single day. However, if the server is under a light load, an object may remain in cache for as long as the TTL dictates. If it's critical that an object is truly inaccessible, for whatever reason, you can purge it within seconds using the Purge Cache application.
To change the default settings, you can modify the Time-to-Live (TTL) value through behaviors, the main one being Caching, or set certain response headers sent by your origin.
Time-to-live (TTL) is the amount of time an edge server will hold an object in its cache, without revalidating whether it has been modified with the origin server. When end-users send a request, edge servers compare the timestamp of the object in cache with the current time. If the resulting age is greater than the TTL specified in the configuration or metadata such as response headers, edge servers must refresh the object before serving it. To check with the origin, edge servers use a conditional HTTP
If-Modified-Since (IMS) GET request. If the object has changed, the origin server sends the new version; otherwise, the origin sends a 304
Not Modified response.
Refreshing occurs only if the object is requested by a client. Also, the IMS GET request is sent only if
Last-Modified-Time (LMT) header is present. If this header isn't present, edge servers send the unconditional GET request.
Your property configuration is the primary method for setting options across groupings of objects, and it's the main method for setting TTL. In behaviors and matches, you set the max-age value that defines the maximum amount of time that fetched responses are allowed to be used again. Usually, you set it to the maximum acceptable value, based on which the remaining TTL is calculated. See the Caching behavior for more information. By applying matches to your rules, you can specify a variety of max-age settings that best suit your needs, for example match on file directories, file extensions, and other groupings.
If necessary, you can override the configuration settings on selected objects with Edge Side Incldes (ESI) attributes, Akamai Resource Locators (ARLs), and specific headers coming from the origin server, such as
This may be of interest to ESI developers. When you use an
esi:include statement to request a fragment for inclusion in an ESI template page, you can use the
no-store attributes to control the caching properties for the requested object.
If you use the traditional Akamaization, you can assign a TTL in the object’s ARL. The ARL relates to a specific request and it takes precedence over both the configuration file and settings in the
Edge-Control header. Contact your Akamai representative for more information.
Edge-Control header is an Akamai specific header. Using the value cache-maxage, you can override other cache directives. The header and value are sent from the origin server's response. This is the fastest way to make a content cacheable or non-cacheable without making any changes to the configuration. The header is suitable either for temporary or frequent TTL changes.
The value used in cache-maxage is an integer, followed by a unit specifier:
d (days). For example:
By default, edge servers do not honor these two response headers sent from the origin server. You can change that setting for specific objects. Enabling each header separately, or both. Once enabled, the edge network honors the following, and only the following,
Cache Control header directives:
no-cache(behaves like setting a zero second
pre-check(serves as a
max-agesetting if there is no
post-check(serves as an Akamai refresh setting)
If there are conflicts between the
Expiresheaders when both are honored, the
Cache-Controlvalue prevails. However, you can't override a no-store metadata setting with a
Expiresheader. To override a
no-store, turn the
no-storeoff. Using response headers, you can turn the
You can use the behaviors to set the
Cache-Controlheaders, and if your property configuration is set to honor
Cache-Control, you can also use Microsoft extensions for Internet Explorer—a post-check and a pre-check directive in the header.
If you set the configuration to honor
Cache-Controlheaders, edge servers use that information for the lifetime of the object if these conditions are fulfilled: you set edge servers to accept
no-cachedirectives, and they receive the header in the response from the origin server.
If you set the configuration to honor
Expires, edge servers use the implied max-age as the lifetime for the object if these conditions are fulfilled: edge servers receive this header in the response from the origin server, and the expiration is in the future.
When you enable honoring and an edge server receives an
Expiresheader from the origin, it may happen that the origin clock isn't synchronized with the Akamai server’s clock. For this reason, the edge server uses an implied max-age to calculate the remaining TTL, and it's the time the edge server uses to set its own TTL. Arithmetically, the implied max-age may be shown as:
IM (implied max-age) = OE (Origin Expires) - OD (Origin Date)
For example, if the origin's
Expiresis set for 5:00 p.m. today, and the origin time is currently 10:00 a.m., the implied max-age is 7 hours. By using the origin date, the edge server calculates the intended TTL. If it used its own date and the origin's
Expires, and if there was a discrepancy between the edge server’s clock and the origin’s clock, the calculated TTL might have been more or less than you intended.
If the received
Expiresis in the past, edge servers use their own current date stamp
nowinstead of the implied max-age.
The choice of an appropriate TTL is based on the time-sensitivity and the nature of the objects. In general, you will want to select the longest possible TTL that would not result in the end-user receiving stale content. The longer the TTL associated with an object the more benefit is received from offloading content. In addition, longer TTL makes means reduced latency, since the requested object is served form an edge server, physically closer to that user.
If the object is popular, even a short TTL can result in reducing the waiting time for the end-user, because the Akamai server prefreshes objects asynchronously with client requests if a request comes during the specified time percentage of TTL. Prefresh is turned on by default and set to 90%. This means that after 90% of the TTL has expired, a request for the object triggers an asynchronous IMS request to the origin while the cached object is served to the client.
For example, an object with a TTL of ten minutes is requested 50 seconds before it expires. The Akamai server first serves the object to the client and then sends an
If-Modified-Since request to the origin server to revalidate the object. This asynchronous update avoids a delay in serving the object at the next request.
To change the default setting, add the Cache Prefresh/Refresh behavior to your property configuration.
If you use behaviors to manage your TTL, you have an option to set TTLs based on a particular starting time, for a particular time period, to be repeated some number of times, until a particular expiration time. The expiration in this case concerns the particular TTL setting, not with the object expiring from cache. You can set short TTLs for objects when they are likely to change frequently and longer TTLs when they are more likely not to change as often.
While choosing time-to-live settings, consider this question: How long do I want Akamai to serve this cached version after I've already changed the content on my site? The answer to this question may be the appropriate TTL for your content.
Extreme time sensitivity. If an object is so time sensitive that it must be revalidated each time it's served, like a breaking news story, then you should either not serve the object from cache at all, or set TTL=0 (zero TTL) so that the object is cached but its freshness is revalidated with each request. The choice of whether to prevent caching (no-store) or assign zero-TTL may depend primarily on the size of your object.
Moderate time sensitivity. If you update the site once a day in the late evening when the traffic is low, you might not mind serving stale content for some time. You can set TTL for most objects to an hour or more. You might even assign longer TTLs and use Purge Cache in the publication process to purge old content after each new publication. However, mind that a change in content doesn't warrant purging the old content from cache. Time-sensitivity is the primary issue. For example, if you make superficial changes to an image and there is no urgency for the user to see the updated version, you can let the changes take effect gradually as edge servers revalidate old objects in cache with the origin server.
No time sensitivity. If content isn't time sensitive at all—for example, an archival magazine article—you can give it a very long TTL. It's probably most beneficial if the origin server isn't bothered with
If-Modified-Sincerequests to confirm the freshness of the object. You can keep the object fresh by either changing the reference in the HTML when the content changes, or using Purge Cache to purge the old content after it has been changed.
Downstream refers to the caching instructions edge servers apply to the content they serve to the clients, such as browsers, mobile devices, or client proxies.
bypass-cacheinstructions override other downstream TTL instructions. If the object can’t be cached, the TTL is irrelevant.
By default, Akamai sets cacheability at the browser to no longer than the remaining lifetime for the content stored in the edge server cache. If the cacheability headers sent by the origin server suggest a shorter time, the shorter time is used.
When delivering content to clients, Akamai servers by default send the lesser of the
Cache-Control: max-age and/or
Expires values received from the origin server, and the remaining lifetime of the object in the edge server cache. This means that the downstream max-age is always equal to or lower than the edge max-age.
Edge servers only update the values in the
Expires headers. They don't add these headers if the origin server didn't send them. However, there are certain exceptions to the default behavior:
If you use no-store or bypass-cache settings in your property configuration to indicate that an object shouldn't be cached, edge servers send cache-busting headers downstream. Any
max-agereceived from the origin server is ignored.
Edge-control: cache-maxageheader is treated as an HTTP
Cache-Controlheader for downstream purposes.
You can set the edge server configuration to compute the downstream caching itself.
If you use centralized authorization, edge servers send cache-busting headers downstream to prevent proxies from caching the responses and serving them to unauthorized clients. While it isn't recommended, you may configure Akamai to not cache-bust for authorized content.
If you use ESI, the downstream cacheability is calculated to be the lowest value of all the fragments that create the output page served to the client.
If you want to set the downstream TTL directly, without relying on the default behavior, you can either use:
Response headers from the origin, including the
The Downstream Cacheability behavior.
ESI configuration file or ESI language controls. With ESI Downstream Time-to-Live, you can only set a specific value in the response. There are no controls for selecting the headers to send or the method by which the value of those headers should be calculated.
If you specify no caching for your object in the property configuration, or if edge servers receive the
Edge-control: no-store header in the response from the origin server, the object isn't cached, and all downstream caching is also prevented.
To bust downstream caches, edge servers send these HTTP headers in response to the client:
Edge servers don't include
Cache-Control: no-store in the headers sent downstream if the origin responds with
Edge-control: bypass-cache instead of
Cache-Control header enabled in your settings, the cache-busting behavior also applies if edge servers receive
Cache-Control: no-cache or
Cache-Control: no-store headers in a response from the origin server. It's also true if the origin response included the
Expires header in the past, but no
Cache-Control: max- age.
Note that the ARL-based instructions take precedence over the
Expires headers. However, the cache-busting behavior does apply to objects that take their coherence settings from the property configuration.
If you want to cache in edge servers but prevent downstream caching only, you can:
In the Downstream Cacheability behavior, with Caching Option set to Allow caching and Cache Lifetime set to Fixed value, set the maxage value to -1.
Use the ESI function
$add_cachebusting_header(), or set the ESI downstream TTL configuration attribute to -1.
Set the response header to
Edge-control: cache-maxage=1h, downstream-ttl=-1. This instructs edge servers to cache the object for one hour while at the same time passing downstream cache-busting headers on each request.
In some cases, setting a TTL duration may not suit your needs. Imagine you need fresh content served the moment you publish it, for example, a market quote that needs to reflect the changes in real-time. Or, you might need to perform authentication for each request, and consequently have requests passed through to the origin. There are a few alternatives to TTL that you can apply to your objects.
A unique ID is assigned and embedded in the ARL for each object you onboard to the Akamai platform. As a consequence, every time an object changes, the ARL changes as well, even if the URI remains the same. Reach out to your Akamai representative to have the object ID coherence set as a TTL alternative.
Setting a TTL to zero lets edge servers cache your object, but requires that they revalidate the object with an
If-Modified-Since (IMS) request to the origin each time the object is requested. This option may be appropriate for large, time sensitive objects. If the object is large, the advantage of serving it from the edge of the Internet may outweigh the cost of revalidating the object for every client request.
You may also find zero TTL useful if you need real-time logging of end-user activity, which is a viable alternative to using no-store to ensure real-time logging. Yet, to guarantee fresh content and minimal latency, you should specify a reasonable TTL for the object and set the prefresh option to 0%. This way, edge servers contact the origin server on every request only after they serve the client to prevent increased latency caused by real-time logging.
If the content changes for every request, use no-store instead.
Use no-store if you don't want Akamai to cache the object. As a general rule, if the object is likely to change more often than it is requested—for example, if it's different with every request—it's best to simply prohibit caching. No-store still achieves the benefit of the persistent TCP connections and route optimization between Akamai servers and the origin server.
If you need to pass requests and responses transparently, no-store is sometimes the only solution. You can specify
no-store using the the
Cache-Control: no-store or
Edge-control: no-store directives. You can also use the
Edge Control header to disable the
no-store instruction by entering an exclamation mark before the attribute, for example
For dynamically generated content, it may be essential to use
no-store. However, Akamai also provides ESI (Edge Side Includes) that make it possible to serve dynamic content at the edge, near the end-user.
Bypass-cache is similar to no-store, except that it causes the request and origin response to be passed without removing the underlying object from the cache if it's already there. You can find bypass-cache useful if the object being returned is an alternate for the content that is usually delivered. You can specify
bypass-cache using the the
Edge-control: bypass-cache directive. With the
Edge-Control header, you can also disable the
bypass-cache instruction by entering an exclamation mark before the attribute, for example
To optimize your delivery and have greater control over your content on Akamai servers, you can couple the caching settings with the use of Purge Cache. Though you should always use TTL as the primary content management solution, in some cases where content is time sensitive but changes are infrequent, you may want to set long TTLs to reduce the
If-Modified-Since requests and purge the old content after it has been changed. You also may want to use Purge Cache if an object has changed and you need tight coherence—that is, you can’t afford to serve the stale object for some period of time. For more information, see the Purge Cache documentation.
Updated 4 months ago