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.


ImageEngine WordPress Plugin

ImageEngine wordpress plugin

Our recent release of the image optimization service ImageEngine has been well received by the web community. The results are amazing. It is not uncommon to see image byte size reduced by 50% and more. Even if ImageEngine already is quite easy to implement, we’ve just made it even easier. For WordPress users, that is. We just launched a WordPress plugin which will automatically optimize your images on your WordPress site. The WP ImageEngine plugin can be downloaded from the WordPress plugin repository, or simply search for “ImageEngine” from the plugin page in your WordPress dashboard.

Features of the ImageEngine WordPress Plugin

ImageEngine alone, has some great features. Including automatic conversion of images to the best image format (WebP in most cases), HTTP/2 support and support for Client Hints and more. These features are of course also available through the WordPress Plugin. The plugin will also automatically enable Client Hints for your images, so no editing of themes or templates is necessary. The only think you have to do is to register for an ImageEngine account. You can choose the full version or the Lite version which comes with limited, but spacious, monthly use.

Supports WordPress 4.4 and Responsive Images

Introduced in WordPress 4.4, the way images are handled has changed. Now, a subset of the Responsive Images is implemented. I say “a subset” because is not a part of the implementation. Nor is type specification. Also, the different sizes provided by WordPress, can be considered sort of “random” at its defaults, and not a perfect fit for your theme probably. Although you can customize this, the ImageEngine plugin help you serve the optimal image according to the device and browsers capabilities.

ImageEngine in WordPress 4.4 looks like this:

    <img class="size-full wp-image-6" 
    src="//" alt="DCIM103GOPRO" width="4000" height="3000" 
    srcset="// 300w, 
            // 768w, 
            // 1024w, 
            // 1200w" 
    sizes="(max-width: 709px) 85vw, (max-width: 909px) 67vw, (max-width: 1362px) 62vw, 840px">

Of course the ImageEngine plugin will work (…maybe even better) with the good old image tag too :

<img class="alignright wp-image-435 size-full" 
alt="small" width="200" height="200">

See the Savings

When you have the account, you can log on your account and actually see how much data you save your end users by using ImageEngine. Remember that every byte counts. Globally the average speed you get on mobile devices is 2Mbps. Saving 1 MB image data, will then save your users of 4-5 seconds of download time. Moreover, it is money saved (depending on the plan) for your user, and the page will render faster and use less battery! If you haven’t tried out ImageEngine yet, enter the url of your site in the test tool below, and see the potential optimization:


When you install the plugin, it will automatically optimize all images in posts or pages created in WordPress. If you have images in custom templates or in your theme, there is also a PHP API you can use to display images:
This <?php wpie_get_converted_url( $url_to_convert, $options );?> will output // where the parameters are:

  • $url_to_convert is the full url, including http(s)://, to the image.
  • $options is an array of configuration options. If not set, values from plugin admin page will be used. The array looks like this array("key"=>"xyz","key_type"=>"normal","w"=>0,"h"=>0,"pc"=>0,"fit"=>"")

Configuration Options


Like most other plugins, WP ImageEngine also has a configuration page. You find it under the settings menu on the WordPress dashboard. The most important thing to do there, is to register for an ImageEngine account to get your unique token. This token is the first part in your hostname to the ImageEngine service. All your images will be prefixed with this.

There is also a switch you can use when you’re developing on a local machine, like localhost, so that images are actually displayed. This is because the local image sources WordPress generate is not accessible from the internet.

The advanced options are in most cases better off left at their defaults. But you can tweak the default width, height (fixed and relative) and the fit method.

So, nothing to wait for if you’re a WordPress user. Install the plugin.


Mobile Device Usage Info Available at MOVR Visualization Now!

On November 6, we released our MOVR report for 2015 Q3, providing timely information on mobile device usage around the world. At the same time, we introduced our MOVR Visualization tool.

MOVR-Vizualization Mobile Device Usage

For users of MOVR data, you will find this interactive tool very helpful and informative. You can:

  • Select a timeframe: We provide weekly updates of MOVR mobile device usage data
  • Select a region: You can lookat the global trends of mobile device usage or drill down on a continent
  • Select a manufacturer: Select from the world’s top 15 device manufacturers
  • Select a form factor: Narrow down to Smartphones, Tablets, or Feature phones
  • Select a chart type: Trend, Starburst, TreeMap, WorldMap
  • Save to image: Download a high-quality PNG of the chart you have generated
  • Share via URL: Copy the URFL of the chart. That way you can share it easily or dynamically insert it into your our report.
  • Download information: Combine the raw information with other data sets for even more insights into mobile device usage.

To get full access to MOVR Visualization, you need to register for a free ScientiaMobile account. Current WURFL or ImageEngine customers are already registered.

Optimize Images with ImageEngine

A while back we launched a free image optimizing service over at This turned out to be a huge success, and we’re now serving billions of images every month, saving the end user kilobytes of data per image!

We’re not only happy because of the great numbers, but also because this proves that the web industry is increasingly concerned of performance and optimization. Another reason may be that the Responsive Images specification didn’t turn out to be the silver bullet after all.

We got some feedback on our blog post where we wrote about Responsive Images and the need for server side logic to make it work properly saying the examples we used were “artificial” and that the scenarios were just not realistic. As the time has passed however, more blog posts out there has concluded similarly. Jason Grigsby of Cloud4, stating it very clearly that the image logistics is work is a task for the server.

Further, Ilya Grigorik of Google takes it a step further with spear-heading Chromes implementation of Client Hints. Google’s work with Client Hints is indeed confirming that services like ImageEngine has a very important role to play in the web performance space.

Client Hints support

Speaking of Client Hints. ImageEngine has full support for Client Hints. This means that we’re  now able to offer lazier precision even on sites using responsive images on desktop browsers! For everything else, we have WURFL which does the same job, but for mobile devices.

HTTP/2 support

Another great thing that we have launched is full HTTP/2 support! Which is surprisingly well supported in both mobile and desktop browsers! The end user will notice this by faster image download because the browser does not need to connect to the server for every single download. Potentially saving hundreds of milliseconds.

webp Support

Yet another feature which we implemented because the browser support is broad, is support for webp, Googles own light weight image format. We only serve webp if the browser supports it, of course. This will also save another 25-34% of image data compared to jpeg.

Launching ImageEngine

So, to summarize, the popularity of the free “WURFL Image Tailor” (WIT) service has been overwhelming and timely. That’s the reason why we have spent a lot of time lately to make it even better with support for the most important new features that will greatly impact performance on your web site. In the process we also renamed the service. Now, it is called ImageEngine. We still offer the free edition, now called ImageEngine Lite. From a free user’s perspective the biggest difference is that you now have to sign up for an account. This is because we need to identify who is responsible for the traffic in case something happens.

We’ve also done a few tests of course. The below image shows the difference between three scenarios:

  1. A site with basic, old fashioned <img> tags
  2. Responsive images implementation, including picturefill.js
  3. <img> tags with ImageEngine.


The diagram speaks for itself. Now, you can try out ImageEngine for free!

  • Categories

  • Recent Posts

  • Tags

  • Monthly Archives