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.
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
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:
Time to Live
1 – 3 days
6 – 12 hours
Product listing pages
2 – 4 hours
Product detail pages
30 minutes – 2 hours
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).
“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.
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:
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.
Click here to learn about cache keys in more detail.
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 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
HTTP/2 has been around for a few years now and has introduced multiple benefits over HTTP/1.1, such as multiplexing and concurrency, stream dependencies, header compression, and server push. By enabling HTTP/2, you will not need to change your website or applications to ensure they continue to work properly. End users will reap the benefits by connecting to the Akamai edge server over HTTP/2. This is also a prerequisite to enabling the Adaptive Acceleration feature.
Adaptive Acceleration is a suite of bundled features that automatically accelerates and optimizes content delivery using a variety of methods. Powered by intelligence gathered from mPulse, Adaptive Acceleration consists of:
Automatic Server Push: The Akamai edge server will push CSS and JS objects down to the browser before they are requested for faster rendering times
Automatic Preconnect: Connections to your third parties will be initiated early in the request process to reduce latency when it is time to request the content from them
Automatic Font Preload: Accelerates pages by telling the browser which fonts it will need before it processes the page
Resource Optimizer: Automatically compresses CSS, JS, and SVG files using Brotli compression, which can result in overall page weight and transfer size reduction by 5% to 25% over gzip
Prerequisite behaviors that must be enabled: HTTP/2, mPulse
If an object is not already in the edge server cache, Prefetching is a feature that will instruct the edge server to fetch the object from your infrastructure prior to the browser’s request. The edge server will receive and parse the HTML from the origin before the browser does so it can begin requesting the needed object immediately and pull it into the edge server cache. Prefetching can be thought of as “just in time” caching. Make sure this is enabled along with its counterpart behavior: Prefetchable Objects. Prefetchable Objects tells the edge server what type of content is eligible to be prefetched.
If an object being requested from an edge server has a TTL that will be running out soon, Prefreshing will instruct the edge server to asynchronously check for an updated object to keep it fresh in the cache. When this feature is enabled, the edge server will refresh the cache by default for an object once it reaches 90% of its TTL. Although 90% is the default value, if you feel that certain objects would benefit from being refreshed more frequently, you may consider decreasing the value to 50%.
Script Management is a feature that can help inventory all scripts deployed across a hostname and identify which of them perform well and which perform poorly. Once you’ve identified the scripts you want to take action on, you have the ability to defer or block any script that Script Management identifies.
By blocking, Akamai is instructing the browser to block the script altogether
Script Management also contains a feature called SPOF Protection that moves a call for a script to the background if it impacts page loading. SPOF Protection intervenes when a script exceeds a timeout value, which adjusts automatically in response to network conditions. Learn more about Script Management here.
Adaptive Image Compression
Included with Ion is a feature called Adaptive Image Compression (AIC). This feature will automatically apply compression to JPG images based on the network quality an end user is currently experiencing. For example, if the user is on their mobile device using a 3G connection, AIC will apply a higher level of compression to the image so that the user is able to download it faster than a high resolution image. Although the result may not be the best quality image because of the standard JPG compression, the end user experience tends to be much better since they are not staring at a spinning loading icon.
As an alternative, you may want to consider exploring Akamai Image and Video Manager solution (not bundled with Ion), which will not only take network quality into account, but will also support compressing additional image types using our sophisticated Perceptual Quality compression. Perceptual Quality intelligently calculates and applies a precise degree of compression for the maximum level of byte reduction that is imperceptible to the human eye. In addition to Perceptual Quality, Image and Video Manager will also automatically convert and deliver the image using the best file format for the end user’s device.
IPv6 is an enhancement that is often forgotten about when it comes to web performance. Given that a majority of mobile devices and mobile/broadband carriers support IPv6 today, enabling the dual stack on Akamai is a simple way to improve the experience for your end users. By enabling the dual stack, you are instructing the edge server to hand out either an IPv4 or IPv6 address during the DNS resolution process (based on what the requesting device can support), thus allowing your end users to inherit the benefits of eliminating network address translation and the more efficient routing that comes with IPv6. Your origin does not need to support IPv6 as this will only occur on the client connection to the Akamai edge server.
Reporting and monitoring
Now is also a good time to begin reviewing the reporting and monitoring capabilities you have available not only via Akamai, but also in-house as well. If you have Application Performance Monitoring or real user monitoring tools, sync up with your team to understand what metrics are the most relevant and important. (We covered this in more detail in part two of the Holiday Readiness blog series).
On the Akamai side, start to familiarize yourself with the following Traffic Reports in order to understand how your websites and applications are performing throughout the duration of the holiday season:
Today’s Traffic: Provides near real-time visibility into the last 48 hours worth of traffic including edge vs. origin bandwidth/hits and offload
Traffic: Provides similar visibility to Today’s Traffic, but with the ability to review the last 90 days worth of traffic
URL Traffic: Provides insight into traffic-per-URL to understand the offload ratios and hit counts for each object on your site over time
Click here for a list of all available Traffic Reports and their descriptions
If you are not currently an mPulse Enterprise customer, we recommend enabling mPulse Lite. mPulse is Akamai’s real user monitoring solution that can help you understand how fast your website is via standard metrics, like page load time; perceived metrics, like Time to Interactive and Time to Visually Ready; and Google Core Web Vitals. Although there are restrictions to the amount of traffic mPulse Lite will record, you can still gain basic insights into the performance of your website or application. Plus, it is a prerequisite for some performance optimization features above, such as Adaptive Acceleration.
As we inch closer to the busy season, on top of the security and disaster recovery topics we’ve already covered, improving performance and offload is another tool in your arsenal to set you up for success. There is still roughly one month left until some customer code freezes begin, so act now to ensure you have enough time to implement and test.
Next month, be on the lookout for the final blog in the Holiday Readiness series in which we will cover final thoughts and last-minute items on the checklist before the rush of traffic is here. As always, wishing you a successful holiday season!