Akamai Diversity
Home > Pierre Lermant

Recently by Pierre Lermant

A practical guide to web resource caching, 2016 update

Significant technology and usage changes have emerged since the initial publication of the practical guide to web resource caching. This updated edition revisits the recommendations issued earlier and brings new focus on:

  • Fast Purge, the ability to invalidate or delete assets from the Akamai network in five seconds, and
  • API usage, prevalent in native mobile and single page applications.

How does your web site performance compare to the average?

I'm often asked by our customers how their web sites compare to the industry averages, in terms of speed and size. While the numbers vary depending on the business, devices used and audiences, we can leverage the information gathered by httparchive.org to report overall metrics for desktop home pages.

Dynamic Content: A Short TTL as an Alternative to Purge?

Purging URLs at the Edge when its underlying content changes at the origin infrastructure may seem to be the best way to manage a website dynamic content. Or is it?

In this post, we'll explore the pros and cons of purging, and offer an alternative when appropriate.

Top Five Web Performance Pitfalls: How to prevent them

Every web site is unique, and each presents its own set of performance challenges and opportunities. These challenges can be exacerbated by perfectly reasonable business goals and site features, which can negatively affect the overall end-user experience. Business requirements (more features/ads), analytics (data beacons), time to market (we want it now), resources and cost constraints are all considerations that should be balanced with their effect on delivering a web experience that meets end-user expectations.

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.

Part 2: A practical guide to web resource caching

The first part of this series reminded our reader on the best practices for caching and emphasized the need to isolate personal data from any page view content.

In this second blog post, we will provide actual caching value recommendations for client browsers and edge servers. We categorize each resource by time sensitivity, list the main observed use cases for each of them, and propose TTL values for the client as well as for the edge server. When appropriate, we differentiate recommendations based on the edge invalidation policy.  

Resource is not time sensitive, points to static content. 

This is the best caching scenario. Always strive to make resources time-independent.

  • Images
  • Any versioned content: www.example.com/v13/js/main.js

Recommended TTLs: Edge and Client TTLs: 3 months

Resource has low time sensitivity ( Staleness > 1 hour)


  • Search result listings
  • User reviews
  • Backward compatible resources, e.g. JS or CSS
  • Search engine targeted pages
  • Generic ads

Recommended TTLs:
  • Edge TTL: 1 hour to 1 day if no invalidation, else 2x the refresh period, e.g. 2 days for content updated daily
  • Client TTL: 2x median user session duration , or 15 min if unknown

Resource has medium time sensitivity (15 m. < Staleness < 1 h.).


  • Social updates, user comments 
  • Category listings
  • Flight and other schedules
  • Weather forecasts
  • Context sensitive ads
  • Product prices or availability. (Upon purchase/reservation, non-cacheable requests to pricing/availability must be made to guarantee the transaction)

Recommended TTLs: 
  • Edge TTL: 15 min. to 1 hour if no invalidation, else 2x the refresh period, e.g. 2 hours for content updated hourly.
  • Client TTL: 10 min. or less.

Resource has high time sensitivity (Staleness < 15 mins.). 

  • Breaking news 
  • Finance tickers
  • Sports scores

Recommended TTLs:
  • Edge TTL: 30 sec. to 15 min. Invalidation is discouraged
  • Client TTL: 0. Validation with edge server must be performed for each request

Resource has personal information.
  • Origin system generated: recommendations, messages
  • User generated, e.g. personal settings, shopping cart

Recommended TTLs:
  • Edge: Do not cache
  • Client TTL: If origin generated: 2x median user session duration, else do not cache

Resource cannot be served stale, yet is cacheable
Non-personal, popular and time-critical large objects that change at unpredictable times

Recommended Edge and Client TTLs: 0. Resource can be cached, however validation with Edge (from client) and Origin server (from Edge) must be performed for each request

If you would like to understand how to best implement these recommendations or present a use case that is not covered here, please contact Akamai professional services.

Pierre Lermant is an Enterprise Architect at Akamai

A practical guide to web resource caching, part 1

Web resource caching provides the dual benefit of reducing load on the origin infrastructure while accelerating the content delivered to the clients. Yet, because of business and technical requirements, it is often difficult to select the best caching rules for the client browser and the Akamai edge servers. In this 2-part blog I will review industry's best practices and offer recommendations for common use cases.


Part 1 will walk you through all the parameters impacting caching policies. Part 2, to be published soon, will provide actual TTL recommended values for various contexts and use cases.



●    TTL: Time to live of a cached resource.

●    Cache keys: Define a set of parameters that scope the caching of a resource. The client cache key is typically the full URL, including the query parameters. Akamai edge servers cache keys can be tailored to the application and resource at hand, and allow for dynamic caching, based on cookies, headers, query strings and other parameters.

●    Resource time sensitivity, or staleness: The amount of time a resource can be served stale without breaking any significant functionality or user experience. It is not to be confused with the object rate of refresh, which indicates how often the object is changed at the origin. Time sensitivity, and not refresh rate, is a main TTL driver.

●    Personal information: Hold data that is unique to a given user.


What is cacheable?

●    Edge caching: Everything can be considered for caching at the edge, except for content that is personal or must reach the origin for critical logging or business reasons. Even a few minutes TTL can enhance the user-experience and avert origin breakdown in case of request bursts.

●    Client caching: While providing the shortest path to a given resource (no N/W traffic), it must be used with caution, as it cannot be invalidated. Personal information can be considered for caching. 

It is highly recommended to not embed personal information in the page view (i.e. html) so it can be cached at the edge and shared amongst users. Instead, have the client fetch personal data through ajax calls or by reading dedicated cookies.

When to use Edge caching invalidation?

Invalidating a piece of content is enticing as it can be automated and extended TTLs can be prescribed. However it must be used with the following in mind:

●    The purge/invalidation process can create significant traffic spikes on the origin. If many resources are invalidated concurrently, or if it is performed during traffic peak hours, this may negatively impact the origin's ability to serve the requests in a timely manner.

●    It is most beneficial if automated and synchronized with the underlying systems updating the content. e.g. CMS or code release process.

●    It should only be considered for content that can be served stale for up to 10 min, as the invalidation/purge process is not immediate.

Client vs Edge caching

For each resource, business rules define a permissible overall staleness, which cannot fall below the sum of its client and edge TTLs. We will address how to partition the 'staleness budget' between the client and edge servers in our next post.  We will also provide actual TTL values for both the client and the edge server. Stay tuned and please check back on this blog.

Pierre Lermant is an Enterprise Architect at Akamai