Caching static content at the edge, like images and scripts, is only the beginning in terms of offloading requests from the origin and giving users the best experience. Dynamic content has long been thought of as a web resource that can serve different content for the same URI (Uniform Resource Indicator). A common misconception is that this content is always non-cacheable. When you break it down further, you realize that often times there are specific conditions that need to be met to produce different content, and that these conditions can be predefined. Caching more content not only reduces page load times, providing a more responsive site for its users, but also frees up computing cycles at you origin infrastructure to service transactional requests such as inventory checks, adds to the cart, and check-out more effectively.
What is Dynamic Page Caching?
Dynamic Page Caching (DPC) enables the caching of HTML pages based on request path, query strings, cookies, and request headers. Using any combination of attributes from an HTTP Request, Akamai will decide when and how to cache the responses and serve them. These attributes define the conditions that need to be met in order to serve "dynamic" pages from cache, while other requests that must go to the origin, will continue to do so.
The benefit of this is three-fold:
Reduce the number of requests to the origin infrastructure
- Leverage the scale of Akamai offload responses from your origin
- Allows additional processing to occur without upgrading the origin infrastructure
Improve the Time to First Byte (TTFB) and overall performance
- Improve the user experience
- Get the user engaged more quickly to increase chance of conversion
Free up the origin to operate more efficiently for truly dynamic requests
- Improve performance of transactions, like adding to the cart and checkout
A Real World Example: Anonymous vs. Logged In Users
A common use case is that of the anonymous user. In the example of an e-Commerce store, users who are not logged-in often see the same content and represent a large portion of hits to the site. Depending on the site design, these users' empty shopping cart and "Log In / Register" message in the header may be the same for all anonymous users. In this case, understanding if the user is anonymous based on attributes of the HTTP request will allow those users be served cached content.
Often times, a cookie is set, or can be set, for logged-in users but not for anonymous users. Akamai can check that this cookie is not present in the HTTP request, and serve the HTML content from cache.
Dynamic Page Caching can be configured through the Akamai Property Manager:
In this example, absence of the "frontend" cookie determines if the user is anonymous. Contact Akamai Professional Services to ensure your configuration is setup according to your specific business requirements
Let's take a look at a real life example for a medium-size retailer's offload statistics when implementing this setup, specifically let's take a look at the homepage.
There are two ways to measure offload. One way is by the number of requests or hits, and the other is by the number or bytes or volume.
Measuring over the course of 30 days:
the offloaded percent represents the
amount that was served by Akamai without contacting the origin, freeing up
precious resources, while also providing a faster experience by serving from
cache. The cache Time-To-Live (TTL) was
set to 10 minutes in this example.
Using Akamai's Real User Monitoring (RUM) measurements, let's compare:
With DPC on, 74.3% of users saw content rendering (First Paint Time) in their browser in two seconds or less, while with DPC off, only 22.2%.
As studies have shown, slower pages result in increase in abandonment, and 73% of mobile users surveyed in a recent study reported that they've encountered websites that were too slow to load, and 40% of users abandon a website that takes more than three seconds to load.
Here is a snapshot from WebPageTest:
In this example, the Time to First Byte (TTFB) was reduced by 77% and First Paint Time was reduced by 33%. The longer the origin server takes to generate the HTML, the more dramatic the reduction in TTFB will be. The time it takes the server to generate the HTML is called the "think time", and because the HTML is served from cache, the origin server think time is eliminated. The quicker the user's browser receives content, the faster it can begin to process it and start painting on the screen making your users happy!
Why serve from your infrastructure when Akamai can do it for you?