Get WURFL Release 1.8

WURFL Release 1.8
ScientiaMobile has released version 1.8 of its WURFL API. To get the best possible performance from your WURFL solution, you should have both the latest API (1.8) and our most recent XML (released weekly to Commercial license customers).

What’s New in Release 1.8

  • Improved detection of iOS 10.
  • Improved ability to identify if the requesting HTTP client is an App
  • Adding of WURFL Updater that simplifies the setting up and maintenance of weekly XML file updates (Java only)
  • Improved decoding of User Agent strings containing special characters
  • Improved identification of MIUI devices

Release 1.8 is available across all WURFL products. WURFL OnSite users can download here.  WURFL InFuze users can sign in and download from their account.  We have moved downloads of the WURFL OnSite API to, which requires an account username and password. Please contact us if you have any issues registering for an account.

WURFL Cloud, WURFL.js, and WURFL InSight customers will automatically benefit from Release 1.8 – no downloads necessary.

Beginning with WURFL Release 1.8, ScientiaMobile will only offer WURFL OnSite under either a Commercial license or an Evaluation license. Previous users of AGPL or other Open Source license versions are welcome to evaluate WURFL OnSite for 30 days under the Evaluation license. After 30 days, you can contact us here to acquire a Commercial license. We also offer several other products that may fit your budget and needs (WURFL.jsWURFL Cloud).

Add ImageEngine To Your CDN Mix

On the web today, there is a strong focus on performance. A website must be rendered as fast as possible for all users regardless of their geographical location, device capabilities, latency and bandwidth. The value of a fast loading web page is well documented. If we look closer at the drivers that slow down a website, then we discover that mobile devices connected through the telco network have a much slower experience. This is because of the resources available in this context. However, there are many things we can do to mitigate these slowdowns. One solution is to use a Content Delivery Network (CDN).

CDNs are not new. They’ve been around for many years for good reasons. By geographically distributing traffic to cache servers close to the end user, latency is reduced. Furthermore, much of the traffic is offloaded to the CDN reducing the risk of DOS attacks, or simply helping to tackle peak traffic, which ensure the availability of the site. So, a CDN is usually a very good investment in better performance. Especially for sites with a global target market.

CDN usage according to

CDN usage according to

Check, I have a CDN

A couple of years back, a CDN was pretty much a CDN. Caching and serving mostly static files with little logic applied. Back then, one single CDN might have been enough. Now, there is a trend towards multiple CDNs used on a single site depending on their characteristics. Different content is served by different CDNs. For example, Google’s CDN is widely used to serve fonts and scripts. ChinaCache is great for sites targeting the Chinese market. Our own ImageEngine is great for quickly serving resized images for mobile devices. Along with the trend of specialized CDNs, there is also a trend to apply more logic “at the edge”, which means that various optimization techniques are applied to the cached content as close to the end users as possible. All to ensure better performance and user experience.

Looking at the data from, 18% of the sites are hosting html on a CDN.  If we dive deeper into the data (made available in Google BigQuery), 37% of all subsequent requests made from the initial html page are served from a CDN (July 2016). The reason for the relatively high difference is likely to be the trend of specialized CDNs with edge computing capabilities.

Multiple CDNs

According to the httparchive data, out of the sites already using a CDN, 69% use more than one (excluding references to social widgets like Twitter and Facebook). 45% use more than two CDNs. Google is usually one of the CDNs in this group due to its convenience for serving fonts and scripts. Aside from that, there is a good mix depending on the needs of the site.

sites using multiple cdns

45% of sites use more than two CDNs

ImageEngine: a Pull-Based CDN That Serves Optimized Mobile Images

This is also the reason why we launched ImageEngine. Looking at the CDNs serving images today, none of them address the challenges of images effectively. Especially for mobile users. For many sites the mobile users now account for more than 50%. For example, 50% of Google searches are now performed from a mobile device, and Google asserts that proportion will grow. We know mobile devices have questionable connection quality. And we also know that images accounts for more than 60% of the bytes of the average web page. So addressing the challenge of fast mobile images with an image-oriented CDN is one of the  this is definitely one of the most important challenges to address in order to improve all aspects of using the web.

ImageEngine is a CDN that specializes in optimizing images particularly for mobile users. ImageEngine brings further innovation to the trend of edge computing by applying advanced device detection to figure out how to best size, compress and deliver a given image. Our estimates suggest a saving of up to 60% in bytes transferred.

ImageEngine is a pull-based CDN. Which means that you don’t have to upload or manage your images before you start using ImageEngine. With most other CDNs it is required to upload or somehow push the images to the CDN first. This process adds overhead and complexity to the workflow. With ImageEngine it is just plug and play – no uploading required.

Even though ImageEngine acts as a proxy, it is not as intrusive as other proxy-based CDNs. Typically, a proxy CDN optimizes your site on the fly, by changing the HTML, combining and compressing resources, in an attempt to increase speed. Unfortunately, this approach results in loss of editorial and visual control. Especially for mobile, we’ve seen “less than successful” attempts at this before. But by using ImageEngine, alone or in combination with other CDNs, you maintain the editorial and visual control over your imagery. At the same time, your users can enjoy a snappy user experience.

See how much ImageEngine can save your site:

3 Reasons Your Responsive Web Images Load Slowly. And How To Fix It.

So you have built a responsive web site. Congratulations – all of your mobile web problems are now solved! Well, not so fast. A common complaint is that responsive web sites look great on mobile devices, but the pages and images load slowly. Mobile users expect fast-loading sites and will start to abandon after several seconds. The biggest cause for slow-loading is oversized image payload. Typically, developers choose from 4 options to load images on mobile devices.  Steve Kamerman, ScientiaMobile’s COO, outlines these approaches in an interview at Velocity 2016 – a conference focusing on web performance (start at 2:10)

3 Reasons Your Images Load Slowly

To summarize these approaches:

  1. No optimization. You use a single image size, typically proportioned for a full desktop. Cons: The image is larger than it needs to be for mobile. The result is a large payload. Pages and images load slowly, it is expensive and it drains battery.
  2. Responsive images. The responsive images specification lets you specify different sizes and formats based on the size of the browser window. Cons: You need to pick the breakpoints on beforehand and create an image for each, which means more work for the editor and web developer. Further, you’ll need a polyfill to make sure responsive images will not fail on some browsers.
  3. Lazy load images. By using some clever JavaScript hacks you can first load the html and let a JavaScript figure out which image sizes to load. Cons: You’re breaking the browser’s pre-loader and putting the JavaScript in the “critical rendering path” which significantly slows the page down. There is also a risk of downloading versions of the image you really don’t need (over-downloading).

Read More…

Mobile Device Fragmentation and Proliferation

By Ken Jones
When we started ScientiaMobile, we had the opportunity to talk to several wise people regarding the need for Device Intelligence. At the time in 2010, it seemed like Apps and Apple would take over the world. Their crystal ball predicted much more homogeneity of devices. And when people used their mobile devices, it would be through apps, not a browser.

Fast forward to 2016. The mobile web is very important. If you are not Facebook or one of the top 10 Apps, then most people will be interacting with you (at least initially) via a mobile web browser. Many ecommerce players have learned that mobile Web and Apps need to complement, not replace each other. But the mobile Web presents challenges. The different permutations of devices, OS, browsers make delivery of a successful cross-platform user experience difficult.

At ScientiaMobile, our job is to know every device with a browser on the planet. We provide this Device Intelligence to thousands of organizations trying to optimize, advertise, and analyze their mobile experience. In 2011, our WURFL solution tracked 15,000 device profiles. Now, we have almost 45,000. We call this trend device fragmentation, and it is accelerating.

Today, there are techniques like Responsive Web Design (RWD) to deal with mobile devices. However, to keep your site fast, your client-side code lean, and your images optimally sized, your best bet is to integrate server-side device intelligence solutions with RWD. This design paradigm is called RESS -Responsive Web Design with
Server Side detection. There are many resources (like this article in Smashing Magazine).

And if you want to stay on top of the trends in mobile device, the Mobile Overview Report (MOVR) visualization tool gives you power research tools.

visualization (12)

If you want to learn more about Device Intelligence and tools to manage device fragmentation, we would be glad to hear from you.

Statistics on Internet Traffic – Tablets and Mobile Phones Compared

by Eduardo Casais – Part 2 of 2

Editors Note: We welcome posts from people interested in Device Intelligence. This is the second  of 2 posts that come from Eduardo Casais. Eduardo has been working on Internet technologies since 1997. He has been involved in projects dealing with IP over ATM networks, WWW transcoders for TV set-top-boxes, and service platforms for telecom operators. He led the development of the WAP protocol stack and content adaptation facilities for the Nokia WAP Gateway, and has been an invited expert for mobile Web best practices at the W3C. He has patents on mobile applications and protocols to his credit and contributed to the WURFL device description repository. He currently works in Switzerland as a consultant in the area of mobile Web.

Two mobile market segments

In a previous article, we derived from ScientiaMobile MOVR Internet traffic statistics a few guidelines regarding OS compatibility targets and device pools to test websites and apps for mobile phones. Tablets are endowed with more physical screen space, are mostly operated in a stationary context and always with both hands, and are sold and provisioned through substantially dissimilar, albeit overlapping, channels; hence, that device class warrants a specific analysis.

Device diversity with proportion of traffic covered by the top-10 models.


Figure 1: Device diversity with proportion of traffic covered by the top-10 models.

It makes all the more sense to study tablets separately from mobile phones since those two types of terminals are also readily distinguished by their Internet traffic profiles and the diversity (or lack thereof) of their platforms – as illustrated in figure 1. The chart places each category of terminal within a coordinate system determined by the degree of concentration of the installed base with respect to manufacturers and to operating systems. Each axis corresponds to the Herfindahl-Hirschman index, a standard measure varying from 0% (an infinity of entities with the same weight) to 100% (a monopoly). Furthermore, the coloured portion of each point in the chart is proportional to the fraction of the traffic actually covered by the top ten devices in each category and continental region.

Observations for mobile phones huddle on the left part of the graph. They exhibit a high concentration along the OS axis, reflecting the dominance of Android; a high diversity of vendors, despite the prominence usually given to Samsung and Apple; and a very small share of traffic originating from the top 10 devices, the consequence of market fragmentation by a myriad handset models. Tablet data, on the other hand, stretch across the graph, with two obvious extremes: Africa, whose profile resembles those of mobile phones; and Oceania, a nearly Apple monoculture where a handful of iPad models generates the bulk of Internet traffic attributable to tablets.

In that context, let us answer again the two questions: which OS versions should developers target for mobile services? Which devices should they use for testing?

Read More…

What Statistics on Internet Traffic Teach Us About Mobile Development

by Eduardo Casais – Part 1 of 2

Editors Note: We welcome posts from people interested in Device Intelligence. This is the first of 2 posts that come from Eduardo Casais. Eduardo has been working on Internet technologies since 1997. He has been involved in projects dealing with IP over ATM networks, WWW transcoders for TV set-top-boxes, and service platforms for telecom operators. He led the development of the WAP protocol stack and content adaptation facilities for the Nokia WAP Gateway, and has been an invited expert for mobile Web best practices at the W3C. He has patents on mobile applications and protocols to his credit and contributed to the WURFL device description repository. He currently works in Switzerland as a consultant in the area of mobile Web.

Insight From Data

The MOVR report series confirms trends discussed in other surveys of the mobile Internet: overall supremacy of Android and iOS, the unstoppable rise of smartphones, market shares dominated by just a few popular brands. Further insights are gained by delving into the associated data set made available by ScientiaMobile. The present document harnesses the detailed statistics from MOVR to provide operational criteria for guiding service development and testing, with a focus on mobile phones.

APP development

The MOVR dataset tabulates traffic from devices with an operating system allowing third-party native applications. After mapping each OS version to the date on which it was launched, we can answer the question “How up-to-date is the installed base of mobile software platforms in a specific region?” This information, crucial for app developers, is shown in figure 1 as cumulative distribution functions.

Cumulative traffic distribution relative to date of operating system availability


Figure 1: Cumulative traffic distribution relative to date of operating system availability.

Read More…

jQuery Plugin for ImageEngine

ImageEngine is an image resizing tool particularly suited for web mobile scenarios where it can significantly reduce the image payload of and improve the load time of views. ImageEngine works as a plain and smart Content Delivery Network (CDN). It sits in between your server application and the client browser and replaces the host server when it comes to serving some, or all, of the images of the web view.

In this article, we’ll see how to encapsulate the functionality of the ImageEngine in a jQuery plugin.

An Executive Summary of ImageEngine

Because a picture is always worth a thousand words, here’s how ImageEngine works in a classic web site.

ImageEngine jquery plugin

The browser requests the content of a URL and the web site returns some markup that may include references to images. Next, the browser places additional requests for each of the referenced images. If the URL of images refer to endpoints in the ImageEngine server, then ImageEngine will get the bits of the image from the referenced server and cache it as if it were a plain simple content delivery network.

ImageEngine, however, is not a plain simple CDN and has a significant advantage over all of them: it understands the capabilities of the requesting devices and can serve properly re-sized images and keep them cached for the later use.

The ImageEngine is a tool to reduce the network traffic generated by images. It is not limited to mobile web scenarios, but it surely shines when used in the context of mobile views. By serving images through ImageEngine a web site may guarantee that smaller images are served to non-desktop devices. The list of plus is a bit longer though:

  • You can serve properly resized images to non-desktop devices
  • You can serve images resized as you indicate to just any device
  • You can use ImageEngine as an online resizer tool with a URL-based programmatic interface
  • ImageEngine serves as a CDN and can be expanded to scale as you need
  • ImageEngine reduces the burden of the creating and maintaining multiple versions of the same image to speed up load time on devices

The full documentation of ImageEngine is available in our docs section. Also noteworthy is that ImageEngine is ready for HTTP2 and Client Hints—the emerging proposal for browsers to send information about the preferred size of images to the web server. Client Hints consists of a bunch of miscellaneous HTTP headers that ImageEngine understands today. (For more information on Client Hints, check out Using Client Hints and Image Optimization.)

Motivation for a jQuery Plugin

To use ImageEngine, you must edit the URL of the images you refer in your HTML views. The pattern must be the following:

<img src="[prefix]/[absolute URL of the image]" />

The prefix token is the name of the ImageEngine server. The absolute URL token refers to the absolute URL path of the image you want to display through the IMG element. ImageEngine acts as a proxy and downloads and caches the image for you. This requires that you tweak your image URLs a bit. Here’s a realistic one:

<img src="//image-engine-server/">

Without ImageEngine, the same HTML element will likely be written in a more portable way, as below:

<img src="/images/autumn.jpg">

At the same time, the ImageEngine server name and the current host origin can be added programmatically to the URL. This can happen in either of two ways: server-side or client-side. The details of the server-side approach depend on the specific platform you target, whether Java, PHP or ASP.NET. On the client side, instead, there’s only one possible approach: using JavaScript and possibly a jQuery plugin. The benefit of using a jQuery plugin is just that you keep writing portable code based on relative URLs and the plugin takes care of turning them into ImageEngine compatible URLs on the fly.

Using such an ImageEngine plugin is particularly beneficial if the referenced images are originally stored on the same server as the rest of the application. However, the plugin would still abstract you away from the details of linking in the ImageEngine server.

Skeleton of an ImageEngine jQuery Plugin

Any jQuery plugin is typically built around the following core template.

$.fn.yourPlugin = function() {
 // Some logic here
 return this;

It’s way too simple; and even a bit simplistic. According to a much better starting template is the following:

if (!jQuery)
 throw new Error("ImageEngine plugin requires jQuery");
(function ($) {
 $.fn.imageEngine = function (options) {
  var settings = $.extend({
  // Set default values for plugin options
 }, options);
// Restrict the plugin to process only IMG elements.
 // Implementation here...
 this.filter("img").each(function () {
 return this;

Admittedly, the above template works beautifully for our purposes of speeding up use of the ImageEngine tool. The wrapping immediate function ensures we can freely use the $ symbol in our code ensuring it is bound to the jQuery object thus avoiding any troubles with other libraries that might be working side by side with our plugin in the same host web view. In addition, the plugin only processes IMG elements and ignores every other element that should be picked up by the selector.

The beauty of a jQuery plugin is proportionally direct to its level of customization. Therefore, the more options you provide for developers to customize the behaviour, the better. A common practice in JavaScript is to provide an object set to default values that is overridden during the initialization of the function. The table below lists a few good candidates to become options in our ImageEngine jQuery plugin.

Option Default Description
account “” Gets and sets the account name to use with the ImageEngine backend. The account name is chosen when you sign up to use the service.
addBootstrapResponsive true If set to true, adds the Bootstrap’s img-responsive attribute to the current IMG element.
debug false If set to true, it overrides the alt and title attribute of the current IMG element to reflect the actual URL being used.
format “” If set, determines the format of the image being returned. If not set, ImageEngine will automatically determine the best format. Feasible values are the values supported by the f parameter of the ImageEngine framework.
height “” If set, indicates the desired height in pixel of the resized image. This option matches the h parameter of the ImageEngine framework.
mode “” If set, indicates the desired working mode of the resizing algorithm. Feasible values are the values supported by the m parameter of the ImageEngine framework.
percentage “” If set, indicates the size of the image as a percentage of the screen width. This option matches the pc parameter of the ImageEngine framework.
transparencyColor “” If set, indicates the transparent color to use when the image is resized in letterbox mode.
width “” If set, indicates the desired width in pixel of the resized image.

This option matches the w parameter of the ImageEngine framework.


For more information about the various parameters and related feasible values that can be used, you may refer to the documentation. In light of these options, the code of the plugin becomes:

var settings = $.extend({
 addBootstrapResponsive: true,
 debug: false,
 account: "",
 width: "",
 height: "",
 percentage: "",
 mode: "",
 transparencyColor: "",
 }, options);

The internal implementation of the plugin is built around the composition of an ImageEngine compatible URL.

this.filter("img").each(function () {
 var computedUrl = "//";
 var img = $(this);
// =========================================================
 // Turn the IMG source into an absolute URL
 var absoluteUrl = img.attr("src");
 var r = new RegExp('^(?:[a-z]+:)?//', 'i');
 if (!r.test(absoluteUrl)) {
 absoluteUrl = window.location.origin + absoluteUrl;
// =========================================================
 // Manage ImageEngine settings
 // Fix account reference
 if (settings.account) {
 computedUrl = "//" + settings.account + "";
// width-height || percentage
 if (settings.width || settings.height) {
 if (settings.width) {
 computedUrl += "w_" + settings.width + "/";
 if (settings.height) {
 computedUrl += "h_" + settings.height + "/";
 } else {
 if (settings.percentage) {
 computedUrl += "pc_" + settings.percentage + "/";
// fit mode
 if (settings.mode) {
 computedUrl += "m_" + settings.mode;
 if (settings.mode === "letterbox" && settings.transparencyColor) {
 computedUrl += "_" + settings.transparencyColor;
 computedUrl += "/";
// image format
 if (settings.format) {
 computedUrl += "f_" + settings.format + "/";
// =========================================================
 // Core work
 computedUrl += absoluteUrl;
 img.attr("src", computedUrl);
// =========================================================
 // Further configuration
 if (settings.addBootstrapResponsive) {
 if (settings.debug) {
 img.attr("alt", computedUrl);
 img.attr("title", computedUrl);

The ImageEngine URL points to a user-specific server of the form:


If parameters are specified they will be added to the URL, as in the example below.


A URL is ultimately a string that carries as much information as possible. It’s no big deal for software to deal with URL strings, but a plugin can significantly simplify things for humans.

Using the jQuery Plugin

A jQuery plugin is a plain JavaScript file that you must reference right after the jQuery file in your web views. Here’s how to use the plugin.

<script type="text/javascript">
 debug: true,
 account: "your-account",
 width: 400,
 height: 400,
 mode: "cropbox",
 transparencyColor: "0000ff"

In the simplest case, you need the following:

$("img").imageEngine( {account:"your-account"} );

If you just want to give ImageEngine a try, you could even call it without any parameters. In this case, as shown in the code, the ImageEngine URL is which is only used (and recommended) as a test platform.


Thanks to the jQuery flexibility, you can even turn into ImageEngine endpoints all images in a web view in a single shot. It all depends on the jQuery selector you use to apply the plugin.


ImageEngine is based on the WURFL framework for detecting device capabilities. It requires a fairly convoluted URL to work and details of the various options to be deeply learned. With a jQuery plugin, things come a lot easier and enjoyable.

The source code of the ImageEngine jQuery plugin is available on github.

Getting Started With WURFL In Ektron CMS

The integration in place between Ektron and WURFL allows you to accurately detect mobile devices in order to intelligently serve optimized content. To enable device detection in Ektron you need to take the following two steps:

  1. Enable WURFL in your current Ektron configuration
  2. Get WURFL binaries and add them to your current Ektron configuration


Enable WURFL in Ektron

In order to tell Ektron to use WURFL, you open the web.config file and locate the appsettings tag. Then ensure you have the following entry:

<add key=”ek_EnableDeviceDetection” value=”true” />

Note that device detection is an optional feature in Ektron. You can disable it at any time by simply setting the content of the value attribute to false. More information on disabling WURFL in Ektron can be found here:

Read More…

Visit ScientiaMobile at the 2016 Mobile World Congress Barcelona Conference!

Come find us! We will be located in Hall 8.1, Stand C13.
We would love to meet with you and discuss your mobile device detection needs.
Learn more about Mobile World Congress, click here


Please enter your information below, and we will contact you to schedule a meeting.


Using Client Hints and Image Optimization

Responsive images have been around long enough for most of us to have taken them for a spin, or at least to have learned from the experiences of those who have. Beyond doubt, the responsive images specification is a great win for the web. However, quite a few reports from the front lines suggest that responsive images can become pretty ugly. The good news is that there is a fix! No, not throwing JavaScript at the challenge, but by asking the web server for a helping hand. Enter Client Hints, an initiative spearheaded by Google that is already available in browsers (Chrome and Opera) and that is super-simple to use. Let’s see how Client Hints can reduce both image size and verbosity of the responsive images markup.

This article will not demonstrate the challenges of responsive images. Several other sources have already done that. Instead, we’ll focus on how to address the issues, with a little help from the web server and a new way for the browser, or client, to request images with specific properties. Even if this is called “Client Hints”, it is pretty specific. Let’s dive in!

What Are Client Hints?

Client Hints is a new feature already available with Chrome 46 and Opera 33. More browser vendors are following. It is an initiative by Google (spearheaded by Ilya Grigorik), and, as its progress indicates, it is likely to be “a thing”. The initiative was also recently adopted by the HTTP Working Group.

You can think of Client Hints as the missing link between the browser and the server when it comes to layout information. Instead of specifying every possible image breakpoint, pixel density and format in your responsive images markup, Client Hints append the current scenario to the HTTP request, allowing the web server to pick the perfect fit — also known as content negotiation.

The current way of dealing with responsive images is typically to specify different image sources based on the receiving device’s pixel density, preferred image format and viewport size. If you go through the process of picking breakpoints and formats, your markup might end up something like this:

Brad Frost: I never want to make anything that even remotely resembles this.

Even relatively simple use cases can become quite complex using the responsive images syntax. The code shown here is from A List Apart. (Source: Brad Frost)

I think most of us agree with Brad on this.

To be fair, the example above include different crops of the image too. Which is something Client Hints alone can’t help you with. Still, crafting markup like this is not something a developer or designer should be spending their time on. We need an automated process. Even if the server can generate dynamic markup autimatically, client hints decouples the markup from the image which makes it easier to perform operations on the image without having to worry too much about the markup.

Let The Web Server Know

Imagine if the web server knew the pixel density, the viewport size and also the actual size and format of an image. This is what Client Hints does! Browsers that support Client Hints add a few HTTP headers to requests. The latest draft mentions these hints:

  • DPR
    This stands for “device pixel ratio,” the ratio of physical pixels on the screen to CSS pixels.
  • Viewport-Width
    This is the width of the viewport in CSS pixels. (CSS pixels means the units used in CSS to describe a layout. A CSS width of 100 pixels would be 200 device pixels (DP) if the device pixel ratio (DPR) was 2.)
  • Width
    This is the actual width of an image in real physical pixels (similar to the w descriptor made famous by responsive images).
  • Downlink
    This is the client’s maximum download speed.
  • Save-Data
    This boolean indicates whether extra measures should be taken to reduce the payload.

Downlink and Save-Data are not available in Chrome just yet, but you can imagine their purpose. Let’s focus on the currently available hints. First, we have to tell the browser to send the hints.

Enabling Client Hints In Your HTML

Client Hints flow

With a meta tag added, Client Hints are enabled and additional HTTP headers are sent with the request. (View large version)

You’ll have to opt in to enable Client Hints. The reason for this is that additional data shouldn’t be added to a request unless it is used for something. If it’s not used, it would work against the very purpose by adding data to the payload. Servers can also advertise their support, but for now you’ll have to explicitly opt in by adding the following meta tag to the <head> element in your markup:

<meta http-equiv="Accept-CH" content="DPR,Width,Viewport-Width"> 

That’s all we need. The browser will now append the DPR, Width and Viewport-Width headers to all subsequent requests generated from the HTML, including CSS, JavaScript and so on (with exception of Width, which, in practice, applies only to images). Aside from images, Client Hints might be useful if the CSS file contains breakpoints based on the viewport size or device pixel ratio. Knowing the viewport size before the CSS is returned to the browser, the server can strip unqualified blocks from the CSS file before sending the response. That is another story. For now, let’s look at an example with images.

Our Old Friend, <img>

Imagine we have a page with the image tag below. Let’s display the flower.jpg image at a width of 200 CSS pixels.

<img src="flower.jpg" width="200"> 

With Client Hints enabled, the browser will send the following request to the server:

http headers

With just the meta tag added, the browser appends DPR and Viewport-Width to the request. (View large version)

The browser “hints” to the server that the requesting device has a pixel ratio of 2. As a bonus, we get the size of the viewport, too, since this is known by the browser at the time when the request is being made. Because the DPR is 2 and our page’s design need this image to be 200 pixels wide, we would like to serve an image that is 400 actual pixels wide (200 pixels × 2). But we’re missing information about the intended display size, even if the img tag says width="200". The specification explains that the sizes attribute has to be set in order for the Width header to be sent. In the near future, the width attribute on the image element is likely to be included in the algorithm too, but for now, we’ll have to stick with sizes. The sizes attribute describes the layout and display size of the image. In the beginning, it might be less intimidating to think of it like the good old width attribute or like a CSS property:

<img src="flower.jpg” sizes=“200px"> 

Using pixels might make it easier to “retrofit” existing markup, but using relative units such as vw is recommended to make the page more “responsive”:

<img src="flower.jpg” sizes=“50vw"> 

Now, the request for flowers.jpg will look like this:

HTTP headers

With sizes attribute added in addition to the meta tag, Viewport-Width is added to the request. (View large version)

The browser calculates the intended display size of the image based on the current size of the viewport and the device pixel ratio of the device in time for the preloader to fetch it. You might recognize this from how the selection process work with “regular” markup for responsive images with multiple image sources listed. The difference here is that the information is appended to the HTTP request, rather than an image source being picked from the srcset attribute.

Mind. Blown.

What just happened? Basically, we boiled our verbose responsive images tag down to something that looks very familiar, but with the same responsive functionality. With the pixel ratio and width information, the server can now pick, or generate, the appropriate size of the requested image.

  • The DPR header takes care of resolution switching. We don’t need srcset with x descriptors in our markup.
  • The Width header tells the server the exact width of the image (relative to the viewport) that the browser need to fit in the layout.

Actually, we don’t need srcset at all. The sizes attribute is our new hero! Based on the relative value of sizes, the browser translates this into the actual size in physical pixels. Also, remember that media conditions can be applied if you want the image to have different sizes as the width of the viewport changes:

<img src="flower.jpg” sizes="(min-width: 30em) 100vw, 50vw"> 

The Width header will, of course, reflect this, too. For a deeper dive, Jason Grigsby has written a great introduction to sizes over on Cloud Four

But what about type? Responsive images allows you to define different formats, or mime types, of an image by using the type attribute: type="image/webp"

Client Hints does not cover this, but its older brother, the Accept header, may contain valuable information.

Accept: image/webp,image/*,*/*;q=0.8

This example is from Chrome, which is nice enough to tell us that WebP is preferred. Other browsers might just say */* which basically means, “Send me anything.” In those cases, you could apply your own rules, or, even better, the server could implement more advanced device intelligence solutions to decide the best image format to return to the client.

The Server Side of Client Hints

We could say that, with Client Hints, we’re moving the responsibility of selecting an image source from the browser to the server. This means, of course, that we need to implement some logic to act on the Client Hints server-side.

The bonus of involving the server is that, rather than just selecting the best match from a list of pre-generated image files like the browser does, the server can generate the perfect fit on the fly! On a small scale, this is quite achievable because we have all the information we need in the HTTP header.

However, if this task is a bit daunting and if performance is a priority, a few web services — image proxies, if you will — already support Client Hints. One of them is the free ImageEngine. Using ImageEngine, for example, we first have to “prefix” our images with the URL of the service.

If your image src’s URL is, then we’d have to change the src to http://[key] [key] is the personal token you get when you sign up. As long as the meta tag is present and that sizes attribute is present in the image tags, we’re good to go. Looking at the response with cURL, we can see how the server responds:

$ curl -I -H "DPR: 2" -H "Width: 150" -H "Viewport-Width: 800"

HTTP/1.1 200 OK Content-Type: image/jpeg Vary: Width Content-DPR: 2 … 

The request has a DPR of 2, a Width of 150 pixels and a Viewport-Width of 800. The server then responds with the Content-DPR header, whose purpose is to confirm to the browser what the pixel ratio is of the returned image, so that the browser can fit it on the page correctly. In the example above, the Content-DPR will always be the same as the DPR request header, because ImageEngine is scaling the inputted image to the exact value of Width. As a bonus, even if Width is not set, ImageEngine will fall back to Viewport-Width and then to screen size data from WURFL, a database of devices. If you implement the server yourself, and you chose to mimic browser behavior by selecting the closest match from a set of pre-generated image sources, then the Content-DPR header might be a different number than the DPR hint from the client. The browser will make use of Content-DPR to scale the image to its display dimensions.

Also worth noting is the Vary header. The purpose of this header is to tell the client (the browser or proxy) that the response from this URI will vary according to the value of the Width header. This enables web proxies and content delivery networks to cache the image better — at least compared to caching based on the User-Agent.

Non-Supporting Browsers

Before you run off and start implementing support for Client Hints, you should know that not all browsers support them. The last image tag above will likely mess up a page viewed in a browser that does not support Client Hints. So, what are our options?

Maybe a JavaScript polyfill? In this case, we’d have to rely on cookies, not separate HTTP headers. Cookies would create problems for content delivery networks and cache proxies because the cookie value must be included in the cache key, which would likely lead to cache pollution. Further, and more importantly, the browser’s preloader would not have any knowledge of the cookie’s value.

Until support for Client Hints has reached critical mass, the safest approach is to combine hints with explicit – but relative – widths and heights to make sure the layout doesn’t break. If the browser doesn’t send Client Hints, but the image server expects it, you need the layout to handle an oversized image if that is the default behaviour of the image server. Moreover, to reduce the risk of serving too big an image to a non-supporting browser, an image optimization service is recommended, as described above. ImageEngine is particularly useful because it handles mobile devices very well. If a mobile device does not support Client Hints, then ImageEngine will never serve an image wider than that particular device’s screen.


Aside from automation, the motivation for implementing Client Hints is, of course, image performance. It’s difficult to compose a fair test case, but to give an idea of how a Client Hints-based image request performs differently than a “regular” responsive images request, I’ve put together a little demo with the two scenarios. Below is a table showing the bytes transferred and the actual size of the image put on the wire at different viewports. The selected image breakpoints and viewport sizes in the demo are arbitrary.

Responsive images w/srcset Client Hints with server scaling
Viewport width Bytes Actual width (pixels) Bytes Actual width (pixels)
320 39.6 480 16.1 288
480 39.6 480 28.6 432
800 81.7 768 63 720
1100 138 1024 113 990
1400 138 1024 186 1260

While the preselected image breakpoints span portions of the viewport’s size, Client Hints, along with an image server capable of resizing images, addresses the continuum of viewport sizes. With Client Hints, we have surgical precision. On average, the Client Hints approach serves 19% less data. If we exclude the 1400-pixel viewport, to which the responsive images approach serves too small an image (1024 pixels), then the data served is 32% less with Client Hints, which is substantial.


Full test result can be viewed on WebPagetest (View large version)

The data sample in the chart above is too small to draw any conclusions, but it illustrates the purpose of Client Hints well. No surprises there. Worth noting, though, is the use of DNS prefetching for the external host name Referring to the table above, the time it takes to download the bytes is as expected. Client Hints works as advertised.

(Almost) Ready For Prime Time

While responsive images (image element with srcset and sizes) implemented in markup only allows the browser to pick the closest match from a list of image resources, Client Hints enable the web server to serve an image tailored to the browser’s needs, which in most cases mean less data and better image quality. It does require some programming if you’re implementing server-side support by yourself; luckily, some content delivery networks and web services already support it.

The future of Client Hints looks promising. Adding hints about the user’s connection and instructions to reduce data traffic are on the way. With this information, the server can increase image compression, avoid serving high-density images or reduce the byte size of images in other ways.

As developers, we have no reason not to start exploring Client Hints right now. The key benefits are less verbose and more maintainable responsive image tags, fewer image bytes transferred and, ultimately, happier end users. Only a few steps are needed from you:

  1. add the meta tag to the head element,
  2. put the sizes attribute in your image tags.

Then make, or pick, your image server. I’ve mentioned the free ImageEngine optimization service above, which supports Client Hints. The best way to find other services that support Client Hints is to search Google, because this is a new thing and more providers are announcing support as we speak.

If you want to implement support for Client Hints yourself, the article “Efficient Image Resizing With ImageMagick” is a great start. Also, the open-source imaging service Thumbor is also considering Client Hints.


  • Categories

  • Recent Posts

  • Tags

  • Monthly Archives