Holiday Readiness, Part Three — What you Should be Thinking About Two Months Out: Performance Optimizations

This is the third post in a blog series about Akamai solutions that can help you manage the surge of traffic (both good and bad) that will be hitting the retail industry during the holiday season. Read part one and part two.

October is here, and that means we are less than two months away from the busiest weekend of the year. Parts one and two of the Holiday Readiness blog series covered topics ranging from security checklists to disaster recovery strategies and flash crowd management. If you haven’t had a chance to review those topics and checklists, now is a critical time to start to ensure you are ready for the traffic rush the holiday season brings. 

In this third installment, I will introduce you to optimizations that will not only help with website performance, but also enhance the overall availability of your website or application. The features are all part of Akamai’s Ion solution, which is built to deliver the best experiences to your end users by accelerating and optimizing your website and API content. If you are an Akamai customer, you may have most of these features enabled in your configurations already, but it is still a good idea to review your settings to make sure they are following best practices.

A CDN’s role in performance

First, a quick history lesson: In 1995, the World Wide Web’s inventor, Tim Berners-Lee, knew there would be a congestion challenge on the internet as its popularity grew. As more users and companies brought their machines online, it was only a matter of time before the internet would become slow and frustrating for users. He challenged colleagues at the Massachusetts Institute of Technology to invent methods to deliver website content in ways that would reduce congestion and support the ever-growing number of internet users. 

In 1998, our co-founders, CEO Dr. Tom Leighton and Danny Lewin, developed the mathematical algorithms needed to route and replicate content over a large network of distributed servers — technology that would ultimately solve what was becoming known as the “world wide wait.” In February 1999, Akamai proved its technology by successfully delivering a pixel buried deep on Disney’s site. One month later, we gained significant exposure by delivering the men’s NCAA basketball tournament for ESPN and a Star Wars trailer for Entertainment Tonight, both of which generated historic levels of user demand.

Fast forward to 2021, CDNs like Akamai still play an important role in the performance and delivery of content across the internet. Over the last 20 years, Akamai has grown to have more than 4,200 points of presence, within over 1,400 networks, across 135 countries, and has gained the trust of hundreds of major brands to deliver their web content. Given our physical server footprint, we are uniquely positioned to accelerate and optimize your content anywhere your customers come online, whether it is with our web performance or Edge Compute solutions.

Speaking of web performance, let's jump into Akamai Ion and the features you can implement to improve your performance metrics.

Web performance checklist

Ion is Akamai’s world-class content delivery solution that runs on top of the Akamai Intelligent Edge Platform. It is built to deliver web content to any device quickly and reliably using optimal network routes while applying performance-enhancing features along the way. Akamai’s vast distributed network ensures that your content is offloaded and delivered close to end users to give them a great experience. Now is a good time to begin implementing or confirming that Ion’s features are enabled and working as expected.

Review your caching settings

Among the first things to review while you’re preparing for the holidays are your current caching settings. A good way to do this is by checking the URL Traffic dashboard in the Akamai Control Center to understand what your cache hit ratio is on a per-URL basis. If most of your URLs have an 80% or better cache hit ratio, you are in good shape. Any popular URLs with cache hit ratios of less than 80% are going to be worth reviewing in greater detail to understand why offload is not as high. It is possible that query strings could be polluting your cache keys, which lowers your cache hit rate (a topic we will talk more about below).

In the following sections, we will cover three concepts to help you offload more of your web content: edge caching, browser caching, and cache keys. Lets dive into a few strategies you should consider.

Edge caching

The ability to offload your content to Akamai can not only improve performance for your end users, but it will also reduce the load on your infrastructure. With the rush of holiday traffic two months out, saving as many server resources as possible is the name of the game. By delivering cached content to your end users from an optimal edge server, you will enable a better experience than if the HTTP request makes a long trip around the world to go back to your infrastructure.

Static object caching

A general rule of thumb is that you should cache your static objects on the edge for as long as possible. These include objects like JavaScript, CSS, images, and other objects that do not change often. We recommend caching static objects for at least 7 days or longer, if possible. The fewer HTTP requests back to your infrastructure, the better. If some of these objects change more often than others, you may want to consider splitting them into their own caching rules with more appropriate time-to-live (TTL) values. If some of these objects are updated frequently, take a moment to learn how to clear the Akamai cache using the Fast Purge utility within the Akamai Control Center or automate cache purging via our Fast Purge API.

One strategy to explore is to store your static objects on NetStorage, Akamai’s highly available and replicated global cloud-storage system. Storing static files like JavaScript, CSS, and images on NetStorage, away from your infrastructure, will only further increase server resource availability and decrease load.

Page caching

As we continue to explore the anatomy of a website, we naturally move from static object caching to page caching, which can become complicated depending on how the website or app is built. Caching pages has tremendous benefits as they can generally be heavier in file size than any single static object. Delivering all your pages from your origin all the time can induce a significant burden on your infrastructure. 

Using a typical retail site as an example, let’s list some of the most common pages we see:

• Landing pages: These include the homepage, sales and discount pages, promotional pages, etc; these pages are referenced in email drops and marketing materials

• Category pages: Top-level category pages can be “Men,” “Women,” “Kids,” and so forth

• Product listing pages (PLP): PLPs are the areas of the website that list the products in some type of array

• Product detail pages (PDP): PDPs contain all of the details describing the individual product along with colors, sizes, and so on

In most cases, the complexity and frequency of updates on these pages can increase as you get more granular, so the TTLs are generally shorter as you go down the list. The following are broad TTL recommendations that we have seen deployed across retail customers during the holidays:

Although these recommendations may not be the best fit for all retail sites, they are meant to be general guidelines to ensure you are offloading as much as you can while still accommodating frequent website updates. If you build an API client that can issue purge requests to our Fast Purge API when an update is made on the site, then these TTLs can be increased substantially to allow for a longer cache life.

In terms of complexity, perhaps your website has inventory availability or pricing coded into the pages themselves. If that is the case, you should determine what the highest TTL value is acceptable to your business so you are not displaying cached pages for items that are out of stock. If your site is configured in this manner, in the future, you may want to consider splitting your inventory availability call as an AJAX request. By using an AJAX request, the PDP/PLPs can have a much longer cache life, while the inventory call can be set to no-store or cached for a much shorter time (5 minutes, for example).

Browser caching

“The fastest HTTP request is the one you don’t have to make.” This sentiment has been around the industry for years and still holds true. By implementing a browser caching strategy, you are reducing the frequency of the HTTP requests the browser will make back to Akamai to check for updated content. If the browser can use an object that is already considered “fresh” in its cache, the result is a faster overall experience for the end user.

As a general guideline, downstream caching TTLs should be less than your edge caching TTLs, especially for pages. This allows the object to fall out of the browser cache first so you avoid serving stale content to end users. It is much more difficult to bust the cache on the browser than to purge the content off the Akamai servers.

If you have objects on your site that are updated frequently, but you still want them to be cacheable by the browser, you may want to consider setting a very low or zero-second TTL in your cache-control header or Downstream Caching behavior in Property Manager. This will allow the browser to cache the object indefinitely, but will send an If-Modified-Since request to Akamai each time to check for updated content. Although this will result in an HTTP request back to Akamai, the edge server will respond with a lightweight “304 Not Modified” response to instruct the browser to continue using what it already has in its cache. A response of this type is much more efficient than having the edge server send the full object.

Cache keys

A cache key is a unique string that Akamai edge servers use as a reference to look for website content in their cache when requests are made by the browser. It consists of a few pieces of information like the hostname, path, filename, and query strings. You can think of a cache key as a “primary key” in a database. By default, all query strings in an HTTP request will help form the cache key, which means that even if the page content is exactly the same, regardless of the query strings in the URL, the edge server will treat those pages as separate objects and cache them separately.

For example, let’s take a look at the two URLs below:

• https://www.exampledomain.com/path/to/page.html?utm_source=abc123

• https://www.exampledomain.com/path/to/page.html?utm_source=def456

In this scenario, “utm_source” is a well-known query string appended to certain URLs for marketing purposes. Yet, the content displayed on “page.html” will be exactly the same regardless of the “abc123” or “def456” values. 

The ideal scenario is to instruct the edge server to treat these two URLs as the same object, thus increasing the cache hit ratio and achieving more offload. This can be accomplished by adding the Cache ID Modification behavior to your caching rule to exclude the query strings that should not be part of the cache key.

Ion optimizations

Next, let's jump into the optimizations that you should review and consider implementing with the Akamai Ion solution. Each of these features are built to ensure fast and reliable delivery of your web content to end users.

SureRoute

SureRoute is a feature that accelerates the delivery of your dynamic and noncacheable content by determining the fastest network path across the internet. It works by measuring the round-trip time (RTT) of three network routes between the end user’s location and your infrastructure. Whichever route has the fastest RTT wins and will be, by default, used by multiple end users connecting to the same edge servers for the next 30 minutes. The RTT is measured by placing a lightweight object on each of your origin servers (or load balancer) that the Akamai edge server will look for. This file is called the SureRoute Test Object.

Now is a good time to make sure SureRoute is functioning properly to ensure you are taking advantage of route optimizations. Check that the SureRoute Test Object:

• is not cacheable by the edge server

• returns a 200 OK HTTP status

• is not behind any authentication

• is at least 8kb in size