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