Add Adaptive Acceleration to your Ion property to improve HTML page load performance. It syncs with ​Akamai​ real user monitoring to gather navigation and resource timing data and stores that data in a policy that's associated with your hostname. As requests for your hostname continue, policy data is gathered and reviewed to identify key resources. This allows Adaptive Acceleration to provide these resources to an end user's browser ahead of time, reducing the load and render time for your web pages.

This walks you through the steps you'll need to follow to set up this recommended feature.

👍

Prefer an API?

If you'd rather use an API to set up and manage, you can use a combination of ​Akamai​'s Property Manager and Adaptive Acceleration APIs. Check out the workflow.

1. Meet some prerequisites

Before you can configure Adaptive Acceleration, you need to do a few things:

• Your Ion property needs to be secure. You need to define property hostnames that connect the end user to the ​Akamai​ edge securely via HTTPS. You can use any of the secure methods ​Akamai​ offers: Enhanced TLS, Standard TLS, or the ​Akamai​ shared certificate.

• Enable a beacon source. Timing data is collected in "beacons" and sent to a source—a real user monitor. Adaptive Acceleration needs to communicate with the real user monitor to get this data. You can select from two: mPulse or Real User Monitor (Classic). To take advantage of all of the features Adaptive Acceleration offers, use the mPulse RUM sub-rule to set it up. It's included in your Ion property by default.

• You need HTTP/2. The HTTP/2 behavior is automatically included in the Accelerate delivery rule. It doesn't require any configuration. Just ensure it stays in your Ion property if you want access to all of the functionality Adaptive Acceleration offers.

📘

Are you participating in the HTTP/3 Beta?

If you are, Adaptive Acceleration is supported with HTTP/3. Review the HTTP3 Support (Beta) documentation to get it set up properly and understand any caveats that apply to its use.

• Get access to the Adaptive Acceleration interface in ​Akamai Control Center​ (Optional). This interface lets you view policies of navigation and resource timing data that have been gathered for use with the Automatic Push, Preconnect, and Font Preload services. You can also use it to reset the data gathering mechanism. You need to have a ​Control Center​ account that's been granted access to this interface. If you're not sure, talk to your local ​Akamai​ admin, or contact your ​Akamai​ account team.

2. Add it in your Ion property

Adaptive Acceleration is added by default to the Accelerate delivery sub-rule in your property.

3. Apply your Beacon Data Source

To start, set Beacon Data Source to mPulse.

4. Enable Automatic Push, Preconnect, and Font Preload

This includes the Automatic Server Push, Automatic Preconnect, and Automatic Font Preload options. They provide optimizations using the beacon data gathered from mPulse. The data is used to create policies that leverage ​Akamai​'s learning engine. These policies can help improve site performance by determining what resources and connections visitors to pages on your site or app will need. The hints and optimizations included in the policy are sent to the browser as soon as it requests a page.

📘

As a recommended best practice, all of these options are enabled by default in your Ion property.

Here's how these features interact with mPulse and Adaptive Acceleration:

1. When you set up Automatic Push, Preconnect, and Font Preload on your property, Adaptive Acceleration starts producing optimizations based on how users visit your site.

2. Adaptive Acceleration analyzes the data for the most-visited pages on your site. It identifies the resources and resource domains on the critical rendering paths for those pages and creates a policy.

3. When subsequent end users request a page in the policy, Adaptive Acceleration sends resources and establishes anticipated connections while the browser is waiting for a response.

About Automatic Server Push

An average page on a website or app requires multiple resources, such as JavaScript, CSS, and images. References to these resources are in the HTML or container pages your origin server produces. Automatic Server Push uses the beacon data to recognize these resources and send them to the end user's browser while it's waiting for a response to the initial request for your website or app. Without it, the end user's browser needs to wait until it's received and read the HTML or container page before it can request additional resources—it can't load those resources until it gets a response for those resources.

Mobile and desktop browsers handle resources differently. So, Automatic Server Push creates separate entries on the policy for each. Automatic Server Push determines which of these entries to use, based on the device's user agent.

Example of an Automatic Server Push

This example shows how Automatic Server Push reduces the number of resource requests needed to display a page's content. Assume that the page www.sportsmemorabilia.com/shop/ includes these resources:

• styles.css
• splashslideshow.js
• saletimer.js
• cart.js

Every visit to that page prompts the end user's browser to submit a separate request for each of those four resources. After sampling some requests for that page, mPulse gathers enough data to determine that those resources "belong" to that page. ​Akamai​ then adds an Automatic Server Push entry to the policy: When you receive the initial request for www.sportsmemorabilia.com/shop/, automatically send these four resources to the browser.

About Automatic Preconnect

This lets browsers anticipate what connections the site needs, and establishes those connections ahead of time. But, it doesn't actually load or request anything.

Example of an Automatic Preconnect

This example shows how Automatic Preconnect establishes connections ahead of time. Assume the page www.moviememorabilia.com/shop/ contains the following resource URLs:

• www.moviememorabilia.com/site/css/ctyles.css
• www.moviememorabilia.com/site/js/splashslideshow.js
• images.moviememorabilia.net/logo.png
• images.moviememorabilia.net/splashimage1.png
• images.moviememorabilia.net/splashimage2.png

Every visit to that page prompts the user's browser to establish a second connection to images.moviememorabilia.net. After sampling some requests for that page, mPulse gathers enough data to determine that www.moviememorabilia.com/shop/ requires a connection to images.moviememorabilia.net. Adaptive Acceleration then adds an Automatic Preconnect entry to the policy: When responding to requests for www.moviememorabilia.com/shop/, tell the browser to establish a connection to the images hostname as soon as it receives the page's HTML.

About Automatic Font Preload

This lets browsers preload the fonts they'll need before they fetch and process other resources. Beacon data from mPulse is used to identify the font requests made by the pages on your site. Font Preload uses this information to add browser-specific preload headers to each font. Once a preload header has been applied, the font will be ready to download before the browser has fully rendered the page.

Example of Automatic Font Preload

This example shows how Automatic Font Preload is used to load fonts before other resources are fully processed. Assume the page www.musicmemorabilia.com/shop/ uses the following fonts:

• titletext.woff
• productprice.woff2
• productdesc.woff2

Every visit to a page prompts the user's browser to submit a separate request for each of the three fonts. After examining user requests for the page, the Adaptive Acceleration learning engine gathers enough data to determine that those fonts "belong" to that page. Adaptive Acceleration adds an Automatic Font Preload entry to the policy: When responding to requests for `www.moviememorabilia.com/shop/, tell the browser to start loading the font resources before it fetches and processes resources referencing the fonts.

5. Optionally add compression

Adaptive Acceleration offers multiple ways to compress and cache resources, such as JavaScript, CSS, and font files, using enhanced compression protocols. This can reduce page weight and potentially improve rendering time for your pages. You can choose from Resource Optimizer or Brotli Compression (beta, only).

Compression feature comparison

In addition to the compression offered by Adaptive Acceleration, there are other ways to set up compression in your Ion property. Before you apply it here, take a look at this table to see how all of the available methods stack up.

Use Resource Optimizer

To enable this, set its slider to On. If you also have access to Brotli Compression, set it to Off. You can't use both.

What's compressed

Resource Optimizer compresses .css, .js, and .svg resources up to 10,485,760 bytes in size. This is the maximum decompressed file size supported for CSS and JavaScript files. It only compresses files that include the extensions.

During the compression, Resource Optimizer sets the downstream TTL of the file to 900 seconds (15 minutes).

What's served

Resource Optimizer serves compressed, cached content on HTTP 200 responses to a request. Both the original and the optimized resources are served under the same cache key: /L/origin-www.example.com/path1/path2/someobject.js cid=___RO_ENCODING=br.

Additional requirements

Before you save your property and enable it on any ​Akamai​ network, you need to apply a few more settings in your Ion property to ensure it's compatible with Resource Optimizer.

• You want to use Caching with a Maxage of at least an hour. This applies to the Caching behavior in the Offload Origin rule. Use any of the settings to enable caching—Cache, Honor origin Cache-Control and Expires, Honor origin Cache-Control, or Honor origin Expires— and set its "maxage" field to at least one hour.

📘

There are several other caching-related sub-rules in the Offload Origin rule, too.

• CSS and Javascript
• Fonts
• Images
• Files
• Other static objects

They're used to override the generic Caching maxage for these specific file types, based on recognized best practices. They all include a default maxage in excess of one hour. For best results with Resource Optimizer, keep these maxage settings as is.

• Only use Resource Optimizer for GET requests. It should only initiate compression and serve compressed content for requests that use the GET method.

• Remove Resource Optimizer from the failover actions. This will prevent JavaScript failover pages from being cached.

• Ensure the Cache-Control header doesn’t contain a private directive. The Cache-Control header on your origin server can be used determine how caching should be applied. You can add the Private directive to it to block the caching of personally identifiable information (PII). This header can't contain this directive if you want to use Resource Optimizer. You can apply this as a setting when configuring Downstream Cacheability.

Resource Optimizer Extended Compatibility

In most cases, Resource Optimizer provides the compression that you need. But, you might see this slider here, instead. It's available in special circumstances to offer additional support. It includes all of the features of Resource Optimizer, but addresses some additional issues:

• It helps to prevent 404 errors from Resource Optimizer back-end requests in ​Akamai​ traffic reports.

• It can help if you've set the resource Time To Live on your origin server using honor cache control headers.

• It can help optimize the final resource when using redirects.

Use Brotli Compression (Beta)

📘

This feature is only available to customers who have signed up for its beta program. Talk to your account team to see if you're eligible to participate.

Set its slider to On, and ensure that Resource Optimizer is set to Off. You can't use both.

What's compressed

Brotli Compression targets text-based content. Compressible content is identified in the Content-Type header of the metadata, or by the file extension. It returns Brotli-encoded responses to compatible browsers for resources with .css, .js, and .svg file extensions. It also returns Brotli-encoded responses for the following content-types:

• application/+json*
• application/+xml*
• application/font-sfnt*
• application/javascript*
• application/json*
• application/protobuffer*
• application/text*
• application/vnd.microsoft.icon*
• application/vnd-ms-fontobject*
• application/x-font-eot*
• application/x-font-opentype*
• application/x-font-truetype*
• application/x-font-ttf*
• application/x-javascript*
• application/x-json*
• application/xml*
• application/x-mpegurl*
• application/x-tgif*
• font/eot*
• font/eot*
• font/opentype*
• font/otf*
• font/ttf*
• image/svg+xml*
• image/vnd.microsoft.icon*
• image/x-icon*
• text/*

6. Optionally enable A/B testing

You may be using A/B testing to compare two versions of a webpage or app against each other to determine which one performs better. If you'd like to include Adaptive Acceleration-related data in your A/B testing model, enable it based on how you've set it up in your Ion property.

Method 1: Enabled using Cloudlets

Cloudlets bring a site's business logic closer to the end user by placing it on the edge of the content delivery platform. ​Akamai​ offers several Cloudlets you can configure to support A/B testing:

• Audience Segmentation (AS)
• Phased Release (PR)
• Application Load Balancer (ALB)

If you've set up A/B testing using any of these Cloudlets:

1. Select Enabled using Cloudlets from the drop-down.

2. If you have multiple Cloudlets set in your Ion property, ensure that the Cloudlet you want to use for A/B testing is set lowest in the rule order. With Property Manager and these three Cloudlets, the last one in the list takes priority.

Method 2: Enabled Manually

This applies A/B testing by redirecting a request to one of two origin servers, based on the contents of a cookie file included with the request. The cookie will use the same file name, but its content will vary, based on the desired site experience. So, when the cookie file is read, origin "A" or origin "B" is contacted to deliver the appropriate site experience.

Before you begin

This process assumes you already have an A/B testing model in place using a cookie in the request. You'll need to know the name of this cookie file.

Set up process

1. Open the Accelerate delivery sub-rule in the Default Rule.
2. Click the Adaptive acceleration child rule.
3. Set A/B Testing Method to Enabled manually.
4. In the Cookie Name field that's revealed, enter the name of the cookie file that you've configured for use in your A/B testing model.

Caveats and known issues

Consider the following points if you're using A/B testing with your site or app:

• Disable Adaptive Acceleration for other A/B testing models. If you're performing A/B testing using a model outside of the two methods discussed above, you should disable Adaptive Acceleration, altogether. You can receive faulty data if you don't. You can always create a new version of your Ion property and enable Adaptive Acceleration when you stop A/B testing.

• Data gathering can take a while. After you push your Ion property changes, mPulse will start to populate its beacon with data for Adaptive Acceleration use. It can take 12 hours or more to get meaningful data. Consider this for your A/B testing.

7. Finish your property, test it, and go live

Continue configuring your Ion property, considering features that are incompatible with Adaptive Acceleration. Then you can finalize it, test it, and go live to deliver your site.

Incompatible features

Adaptive Acceleration isn't compatible or has known issues with other features offered in Property Manager.

8. Wait for data to be gathered and used

With your property live and mPulse enabled as your beacon data source, give it some time to gather data. Data for the Automatic Push, Automatic Preconnect, and Automatic Font Preload settings is gathered and stored in a "property report." This report is used to determine "high usage" assets for your site or app, for use with Adaptive Acceleration.

Additional resources

​Akamai​ offers additional services you can use with Adaptive Acceleration.

The Adaptive Acceleration interface, API, and CLI

You can use these tools to interact with the beacon data collected in the policies for the Automatic Push, Preconnect, and Font Preload features.

• View the policy data. See what Adaptive Acceleration has identified in your policies for early delivery. The Adaptive Acceleration interface on ​Akamai Control Center​ also lets you view warnings and event logs for the policy for troubleshooting.

• Reset the policy. If you've changed your site or you don't want to wait for earlier data to drop out of the analysis, you can manually reset the data gathering mechanism.

View reports

Check out the mPulse reports to access monitoring and reporting tools for beacon data used by Adaptive Acceleration. If you're using the Real User Monitoring (Classic) application, you can access its reports documentation.