Akamai Diversity

The Akamai Blog

And you thought your page could not be cached ...

As we carry out performance evaluations for our customers, we often come across very popular pages that are made 'non-cacheable' at the edge. On top of incurring additional latency and therefore a degraded user experience, it generates heavy loads on our customers' origin infrastructure.
I want to challenge here some assumptions that are made when declaring a page 'non-cacheable', and provide practical short and longer term solutions to improve caching hit rate, by leveraging the Akamai platform.

My page has personalized content

Best practices recommend to avoid embedding end-user specific information in the base page html, and instead fetch it thru ajax calls or execute javascript to read pertaining information from cookies. That way, the base page can be cached for all users.

Yet, for existing pages that do not adhere to the best practices, it is still possible in many instances to cache the page by tailoring the caching policy to the page at hand, a process called 'dynamic page caching'.

As an example, let's consider a page listing the user name when a user is logged-in and showing the number of items in his/her cart.

Pierre Blog Pic 1.png
In many website implementations, the fact that the end-user is logged-in (or not) and has (or not) items in his/her cart is also stored in cookies. We can therefore set up a caching policy at the edge that will only return a cached instance of the page if the cookies indicate that the end-user is not logged-in and has no item in his/her cart.

Pierre Blog Pic 2.png
Since the majority of requests are likely coming from users not yet logged in and no items in their cart, a significant cache hit ratio, and infrastructure savings, can be achieved.
Pierre Blog Picture 3 redone.jpg

My page content changes frequently, or at unpredictable times
Except for very specific use cases, like stock price tickers or sporting event scores, the bulk of the information displayed through a web page can be cached for at least a few minutes. For any site with significant traffic, caching a popular page for even a few minutes can have a tremendous positive impact on the user experience and the origin offload. More guidance on recommended cache TTL (time to live) can be looked up here.

If your base page is big and does not change frequently, yet must be updated almost real-time, you can set a TTL of zero. Upon each end-user request the edge server only checks with the origin if the content changed using the IMS (if-modified-since) mechanism, and it will only burden the origin with the full payload delivery whenever the content changed.

Pierre Blog Picture 5.png
My origin needs to set cookies

The default behavior at the edge when serving html cached content is indeed to not send the set-cookie header information. This may or may not be an issue at all.

If it's not an issue, then nothing else needs to be done and maximum caching efficiency can be achieved for every request. End-user may navigate thru many cached pages without cookies being set before hitting a page requiring a round-trip to the origin, which will then set the appropriate cookies for the site.

If for business reasons it is critical to set a session cookie when a user navigate the site upon the first request, then we can still achieve caching using appropriate mechanisms. For instance:

- We can craft the caching policy to only return cached instances whenever the session cookie is present in the request. This is another example of dynamic page caching.

Pierre Blog Picture 6.png
- Have the client fetch the session cookie through an ajax call or dynamic scripting instead of relying on the origin to set it. 


Although it may sound 'safe and easy' to never cache a base html page, it may prevent tremendous cost savings at the origin infrastructure and degrade user experience. In doubt, reach out to Akamai professional services team who will advise you on the best practice policies to adopt.