Sid Phadkar

Everything you want to know about Fast Purge- FAQs & what's coming!

Blog Post created by Sid Phadkar Employee on May 14, 2017


We have a lot of new & exciting initiatives happening around our Fast Purge functionality. Follow this page for the latest updates, schedules, and FAQs.


What is Fast Purge?

Fast Purge ensures Akamai customers have the ability to update and refresh their content within seconds.


It provides the ability to invalidate and/or delete cached content via API and UI in a rapid and predictable manner; improving offload and performance for fresh event-driven content. Before Fast Purge, customers avoided caching event-driven content, or had to cache it for very short TTLs. Fast Purge hence provides the following advantages:

  • Cache semi-dynamic base pages and API responses for long TTLs without sacrificing freshness, because the Akamai edge will refresh with your latest content as soon as your origin calls Akamai’s purge API.
  • Solves the need to update stale, outdated content in a timely, controlled way.
  • Helps businesses remain relevant, preserve credibility / reputation and reduce abandonment.
  • Grants customers more control over how they serve their content.

What's out there today

Fast Purge is already GA and being used by many customers today! All customers have the ability to purge by URLs today.


What’s coming

Fast Purge by CPCode and Cache Tags are in beta today- this gives customers the ability to purge by CPCode or a natural language identifier (cache tag) within 5 seconds. The CPCode functionality goes LA 07/24/2017 and GA’s in time for Edge’17. The Cache tag functionality enters LA in time for Edge’17 (October) and GA’s Jan’18.


FAQ - General Fast Purge


Q: How do I get access to Fast Purge?

A: Fast Purge is now a part of all base products. It should be available on your account already! If for some reason you cannot find it, please contact Akatec or your Akamai account team.


Q: How do I access the Fast Purge UI?

A: Once logged into Luna, select Publish/Fast Purge from the mega-menu.


Q: How can I use the Fast Purge API?

A: Start by reading this API documentation. You may then begin issuing API requests after generating the proper credentials using the Manage APIs app. You may also find this blogpost about how to migrate to the new API helpful.


Q: Do I still need to use the Transition App?

A: The Transition App is no longer needed.  The V3 API will by default use Fast Purge. If you want to use CCU, please stick with V2 API.


Q: Will Fast Purge be supported on older versions of the CCU API and on PublishECCU UI/API?

A: No. To leverage Fast Purge, you will need to integrate with the new CCU V3 OPEN API. With Purge-by-cache-tag you will be able to emulate most ECCU functionality.


Q: Can I use Fast Purge to refresh my HD libraries?

A: No. You can only use Fast Purge for individual URLs. Please continue to use the HD Content Control Utility for HD links.


Q: Do I use ‘purge by invalidate’ or ‘purge by delete’?

A: We recommend that you use ‘purge by invalidate’ in most cases for its better offload and origin-failure backup advantages.


Advantages of Purge by Invalidate over Delete

  • Invalidate should be the default capability for most customers because it provides:
    • Better offload + better performance.
    • If the edge server cannot reach the origin, invalidating allows us to serve stale content (typically better for customers than serving a failure page).
  • Invalidate is also better for Akamai because it is easier for edge servers to process.
  • Invalidate will cause the edge server to treat content as though its TTL has expired, resulting in an IMS if the origin supports it. If the origin does not support IMS, it is recommended to turn off IMS in configuration, but not to use Delete.


“Delete” completely removes content from all servers and should only be used if:

  • Purging illegal or copyright violating content.
  • For offensive content, which the customer feels strongly should be deleted from all servers.
  • Purging content with corrupted headers where the timestamp cannot be trusted.
  • If in a future event when the origin is unreachable, the customer would still prefer that we serve a failure page instead of the purged content.


FAQ - Fast Purge by CpCode


Q: How can I be enabled for Fast Purge by CPCode?

A: To use this functionality, you should be signed up for our beta program.


Q: What is the expected purge time?

A: All purges are expected to be completed within five seconds.


Q: How do I know my purge is done?

A: Since purges are completed almost instantly, we do not notify users about this today. You can expect your purges to be done in <5secs.


Q: Where can I find documentation around the API?

A: In depth API documentation can be found here-




FAQ - Fast Purge by Cache Tags


Q: What is a cache tag?

A: Akamai introduces a new convenient way to update cached content on its edge servers. If you have a collection of objects that tend to be refreshed at the same time, you can now associate them with a cache tag and later delete or invalidate purge all content possessing this tag with a single purge request. Cache Tags allow a website owner to add tags to items cached at the Akamai Edge. The purpose of tagging is for a customer to be able to purge cached content by calling it with a natural-language identifier, instead of purging by URL, file extension, or CPCode.


Q: What are some typical use cases associated with purging by cache tags?

A: Any use case where the user today needs to purge multiple URLs/objects is a great candidate for cache tags- they can now tag all of these URLs/objects with one tag and just send in one purge request. 

A great use case is seasonal sales on an ecommerce website e.g. Black Friday, Christmas, etc. Once the sale has ended, you can purge all the sale prices across various pages by using a cache tag (lets say ‘SALE’), instead of purging one page at a time.


Q: How are cache tags assigned?

A: You can add cache tags to your cacheable content by providing all tags for each object in an Edge-Cache-Tag HTTP response header to outbound traffic at your origin.

If there are multiple Edge-Cache-Tag HTTP response headers, only the first one will be respected. Multiple tag values inside a header are comma separated.

Note: Avoid including personal information or any other audit-compliant data in cache tag entries.

- If there are multiple Edge-Cache-Tag HTTP response headers, only the first one will be respected. Multiple tag values inside a header are comma separated.


Q: How do Cache Tags work internally?

A: Essentially invoking a purge by cache tag involves the following steps:

  1. A user adds tags to their cacheable web assets by adding an “Edge-Cache-Tag” HTTP response header and a tag value to outbound traffic at origin
  2. A web asset is requested through Akamai
  3. Akamai associates the tag values found in the "Edge-Cache-Tag" HTTP header with content Akamai is caching
  4. The tag sits idle until the user initiates the purge
  5. Once the purge is invoked via the LUNA portal or an API call, all cached content for the specified cache tag is purged.

Q: Are cache tags hostname specific or agnostic?  I.e if I set a cache tag on my static domain content ( and the same cache tag on my primary domain content ( both will be purged?

A: Yes, for our initial beta offering, both will be purged. 



Q: What level are cache tags scoped at today?

A: Cache tags today are scoped at an account wide level. 

In lieu of this, if you have multiple groups or departments using the Purge by Cache Tag functionality within your account, we recommend following some kind of nomenclature that helps distinguish tags created by these different groups. This will primarily benefit in preventing cache tag collisions- scenario where multiple groups create the same tag and purge each other’s content. 

For example, consider an online apparel store that sells both clothes and shoes through two different departments, both of which fall within the same Akamai account. Assume both departments run a promo and tag some of their content as ‘SALE’. Now if the clothing department decides to purge all content tagged as SALE, this will also purge content tagged by the shoes department. To avoid this scenario we recommend having some kind of a nomenclature within departments- this could be as simple as every tag starting with <DepartmentName_>. In this case we would have had two different tags- CLOTHES_SALE and SHOES_SALE and hence prevented any tag collision.


- Also note that since cache tags are enabled at the account level today, they can be used across many CPCodes. In other words, the domain, CPCode, or origin configuration does note matter within an account.


Q: Are there any limits on cache tag purges?

A: Yes- cache tag purges have two limits:

      - Users cannot purge more than 5000 tags/hour (per account)

      - Users cannot purge more than 10,000 objects/min (per account)

     Exceeding either of these limits will throw an error. 


Q: Can you talk more about cache tag nomenclature?

A: When using cache tags, follow these requirements:

  • When assigning cache tags, follow these requirements:

    • A single cache tag cannot exceed 128 characters. If you enter a cache tag exceeding 128 characters you will not see an error but the specific content associated with that tag will not be purged when the purge is submitted.
    • The maximum number of cache tags per object is 128. If you exceed this, the additional tags will be ignored. 
      Note that the default Akamai max reply headers size is 8192 bytes

    Tags in headers are derived from the ABNF token format. (see RFC 7230). Tag characters are limited to this set: [A-Za-z0-9!#$%&'+-/.^_`~|].

    Cache Tags in Edge-Cache-Tag header must be delimited by Comma (,).


Q. How can I get into the cache tag beta?

A: Please get in touch with your account team if you are interested in this.

Getting into the beta also requires certain mandatory pre-requisites:
               a. All properties must be on Property Manager
               b. The account does not use any legacy purges during the duration of the beta (CCU v2 URL, CPCode, & ARL purges, HDPurge, SOAP API). These will work unreliably once the cache tagging environment is enabled. Note that you can continue to use Fast Purge by URL or CPCode or ECCU. 
               c. No properties on networks other than FF or ESSL
               d. Cache tag purge cannot be used on Resource Optimizer. Note that cache tags do work on both pristine and derivative images for image manager

Note that all of the pre-requisites have an account wide scope – not just a contract wide scope