Device Characterization - Forward in Header
Device Characterization (DC) provides additional ways to speed up and optimize your content based on the requesting device's features and capabilities. Property Manager provides two behaviors for controlling these functions: Device Characterization - Forward in Header and Device Characterization - Define Cached Content.
How it works
This behavior works with DC to first identify the requesting devices' characteristics, and then
pass them to the origin server in the HTTP request via the X-Akamai-Device-Characteristics
request header.
Definitions
-
Forwarding. In this context, sending information about the requesting end-user device from the edge server to the origin.
-
Caching. Storing content on the edge server so that subsequent requests for the same content don't have to go to the origin.
What a DC header might look like
The X-Akamai-Device-Characteristics
header uses syntax identical to a cookie header. See an example of a header sent when an Android mobile phone visits a DC-enabled page. In this case, DC is configured to send three characteristics: brand_name
, is_tablet
, and device_os
.
X-Akamai-Device-Characteristics: brand_name=Google;is_tablet=false; device_os=Android
Typical characteristics available for forwarding
Akamai continuously improves the database behind DC, so the list of available characteristics changes over time. Typical characteristics include:
Characteristic | Data Type | Description |
---|---|---|
resolution_height resolution_width | integer | The screen height/width, measured in pixels. |
physical_screen_height physical_screen_width | integer | The height/width of the screen, in millimeters. |
max_image_height max_image_width | integer | The maximum height/width, in pixels, for an image to be viewable when the page renders in a mobile-optimized format. |
device_os | string | The requesting device's operating system (for example, Android, iOS, Windows 10). |
device_os_version | string | The request device's operating system version. |
mobile_browser | string | The requesting device's browser. |
mobile_browser_version | string | The version of the requesting device's current mobile browser. |
brand_name | string | Device maker (for example, Samsung, Apple). |
model_name | string | Request device's model (for example, SCH-I110). |
marketing_name | string | The device model's commercial name (for example, Samsung Illusion). |
pdf_support | true/false | Indicates if the requesting device can read PDF files. |
dual_orientation | true/false | Indicates if the requesting device can rotate displayed content, which swaps the height and width dimensions. |
ajax_support_javascript | true/false | Indicates if the requesting device supports JavaScript. |
cookie_support | true/false | Indicates if the requesting device's browser supports cookies. However, note that cookie support doesn't indicate that the cookies exist. Also, even if the native browser doesn't support cookies, they might be supported via other methods. |
is_mobile | true/false | Indicates if the requesting device is a mobile device. |
is_tablet | true/false | Indicates if the device is a tablet; this is a subcategory of mobile device. |
Special considerations for Apple devices
Most manufacturers of mobile devices include information in the device's user-agent
string that identifies the hardware revision of the device. However, Apple has a policy of not including this information. For Apple devices, DC can identify the iOS version and the browser version, but it cannot distinguish between different models of the same product.
In contrast, consider this user-agent
string:
Samsung Galaxy S3: Mozilla/5.0 (Linux; U; Android 4.1.1; en-us; SGH-T999 Build/JRO03L) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30
Unlike the Apple products, this Samsung user-agent
string includes the model number.
Implementation
Before the edge servers can forward and cache device characteristics, you need to create one or more rules that include the DC behaviors. These are the high-level steps for getting started:
-
Create a rule, and determine match criteria.
-
Add the device-header forwarding behavior, and then select which characteristics to forward.
-
Add the Device Characterization - Define Cached Content, and then select which characteristics to use to create the cache keys.
Step 1: Create a rule and set its match criteria
As with other Property Manager rules, DC rules consist of two parts: match criteria and behaviors. To optimize content and/or cache content by device type, include one or more match criteria that use the device characteristics options.
To create a rule for your DC configuration, perform the following steps.
How to
-
In the Akamai Control Center, go to the property page.
-
Under Manage Versions and Activations, go to the Version History tab and select a version link.
-
At the top of the Rules list, click Add.
-
Select a rule template (for example, the Blank Rule Template).
To narrow down the All Templates list, select a category in the left column.
-
Click Insert Rule.
-
In the Criteria section, click the Add Match button, and indicate the conditions that will trigger Device Characterization. Create additional match criteria as needed.
Step 2: Configure Device Characterization - Forward in Header
Select which device characteristics to forward to the origin. The more characteristics you select, the bigger your forward header will be, which may adversely affect performance between the edge server and the origin. Aim to maximize device-specific content delivery and minimize the number of characteristics you forward to do so.
How to
-
In the Behaviors section, click Add Behavior.
-
Scroll through the behavior menu on the left, and select the Device Characterization - Forward in Header option.
-
Click Insert Behavior.
A new DC behavior appears in your rule.
-
Click the Send These Characteristics field to select what to include in the forward header. You can use the mouse to select from the drop-down menu, or start typing in the box to search the options. Click the X to remove a selection.
-
Click Save.
Step 3: Configure Device Characterization - Define Cached Content (optional)
Select which characteristics are added to the cache key. Every unique combination of values of the characteristics you select will produce a separate cache entry. Therefore, it is recommended that you include only characteristics that request different content for different values.
Consider how characteristics selected in this behavior relate to the device characteristics in the match criteria. You will probably find that the characteristics with boolean values (like
is_mobile
andis_tablet
) are the most effective.
How to
-
In the Behaviors section, click Add Behavior.
-
Scroll through the behavior menu on the left, and select the Device Characterization - Define Cached Content option.
-
Click Insert Behavior.
A new DC behavior appears in your rule.
-
Click the Cache Based on These field to select what to include in the cache key. You can use the mouse to select from the drop-down menu, or start typing in the box to search the options. Click the X to remove a selection.
-
Click the Save.
Adding a greater number of characteristics to the cache key (especially if you select characteristics that have many values) can negatively affect performance and offload.
Tips and best practices
Akamai recommends that any characteristic you add to your cache key you also add to your list of characteristics to forward. Then, you can use the X-Akamai-Device-Characteristics
header to monitor what is being added to your cache key. Likewise, the characteristics in the rule's match criteria should align with the characteristics used in the behaviors. Also, your servers should provide different content based on the values of the characteristics in your cache key.
A good way to approach DC configuration is to begin by describing how you want to classify devices. For example, you might simply divide them by device type: desktop, mobile device, or tablet. Or you might also want to distinguish high-end mobile devices from low-end devices. Create a rule for each class, and use the match criteria to identify all the devices that belong in that class.
Updated almost 3 years ago