Akshay Ranganath

Content Pre-loading / pre-warming at Akamai

Blog Post created by Akshay Ranganath Employee on Feb 4, 2015

Akamai not offers a pre-warming solution as an add-on. You can read more about this in this blog post: The specified item was not found. 


If for some reason, you still prefer the non-productized version, please read on. This blog post pre-dates the productized version. So it will involve variable effort and an on-going support effort for each custom built solution.



Content pre-loading/pre-warming is not offered by Akamai unless implemented as a custom solution. Whenever customers require a pre-warming of cache, the tend to use a synthetic testing agent to create load that populates Akamai cache. The mechanism I propose below is to combine a feature of Akamai for prefetching with a time-based rule mechanism to trigger content pre-warming. Although it may not be as effective as synthetic tests, it will be a better representation of real user traffic leading to more optimal pre-warming of cache.


The Problem

Customers have often asked Akamai to pre-warm/pre-load content on our network. Due to the nature of our distributed platform and geographical distribution of end-users, Akamai does not offer a capability to pre-warm the cache, as discussed in this Knowledge Base article. (https://control.akamai.com/core/search/kb_article.search?articleId=5423) In this scenario, the general recommendation is to use external load testing agents to create a demand for the objects to cause Akamai to fetch the content. Is this the only way? Is there anything better that we can do? Here’s my take at this issue.




Before delving into pre-loading, let me recap the concept of prefetching.


Prefetching is the mechanism by which Akamai can read the HTML response from an origin and start fetching embedded content like javascripts, stylesheets and images before the browser starts to make the request. Since these are resources required for loading the page in the browser, we try to reduce the round trip times by having the object ready in the Edge cache. When the browser parses HTML and request javascripts, stylesheets and images, we serve them without the latency of a round trip to the origin. Thus, by avoiding the think time for the browser, we are able to load the resources faster.


Basic Prefetch.png

Customized Prefetch

Prefetching also has the ability to fetch URLs that are not referenced within the HTML page. There is a setting within the prefetch where an Akamai consultant can add the list of URLs that needs to be prefetched. These URLs will be fetched whenever the associated base page is invoked. For example, the home page (home.html) could be associated with extra URLs named page1.html, page2.html and style1.css. By using the custom prefetch, we can pull these objects into Akamai cache whenever the home.html page is requested by the end user. Here’s the flow for this scenario.


Customized Prefetch - An Example.png

Time based rules

This is a simple setup at Akamai where the Akamai consultant can create rules to fire at specific time. So you could have a rule that says fire a cache purge every Monday morning at mid-night EST. Using this construct, we can have rules that triggers a custom prefetch just before a big event is about to begin. By doing this, we can ensure that the traffic to origin gradually ramps up and prevents a surge and origin overload.

Customized Prefetch for Content-preloading

The design combines the feature of prefetching with a time-based execution of Akamai rules. For example, if a special offer begins at 12:00 hrs and ends at 13:00 hrs, Akamai pre-loading will begin at 11:00 hrs and stop by 13:00 hrs. By using the pre-loading for specific time before the event, the cache will be populated and warmed up.


Going back to our example, assume a special sale has pages /page1.html, /page2.html and /page3.html. We put in the rules for special prefetching on the /home.html. Here’s the rule-set for normal duration and for the special duration on the D-Day.


Normal rule-set

If /home.html  Prefetch all JS, CSS and Images   << Similar to figure 1 >>


Rules from 11:00 hrs to 13:00 hrs, D-Day


If /home.html   Prefetch all JS, CSS and Images   Prefetch /page1.html, /page2.html and /page3.html   Cache /page1.html, /page2.html and /page3.html   << Similar to figure 2 >>


Rules after 13:00 hrs D-Day


If /home.html   Prefetch all JS, CSS and Images   << Similar to figure 1 >>

So the special offers page would be pulled and cached by Akamai servers at the locations driving traffic between 11:00 hrs to 13:00 hrs.  After 13:00 hrs D-Day, the rules would no longer apply and no pre-loading will occur. By then, the special deal will be closed and the hopefully the origin will not be inundated by a surge of user requests.


Generally, the Tiered-Distribution setup of our caching network will ensure a much larger foot-print than just the regions driving traffic. In well implemented caching strategies, we have seen offloads of over 90% for base page and landing pages. Using the solution I’ve proposed, customers should be able to deliver special offer pages and not be burdened by the surge of traffic and freeing up cycles on their servers to do the heavy lifting activities.


Please let me know if this sounds like a solution that would appeal to you.



An alternative solution would to use “Akamai Instant”. Using this solution, a page URLs can be added on the portal. However this solution requires a configuration activation and does not support time-based firing of rules.

For internal users

I have created a setup as a proof of concent. Here are the details:


Thanks to Manuel Alvarez and Mark Adam for reviewing my drafts and suggesting a lot of valuable changes!