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?

Operating system compatibility

Table 1 gives the vintage of operating systems covering 90%, resp. 50% of tablet traffic, both in years and as version baseline (rightmost two data columns).

There is a substantial age discrepancy between the Android and iOS segments. iOS tablets exhibit a time to 50% quantile of 0.5 to 1.2 years (depending on the region), and 2.1 to 3.9 years for the 90% quantile. In comparison, mobile phones typically run a “fresher” iOS version: the 50% quantile is 0.4 to 0.6 years, whereas the 90% quantile is 1.2 to 2.0 years. Conversely, Android is generally “staler” on mobile phones, with a range of 4.1 to 5.2 years for the 90% quantile, against 3.9 to 4.3 years for tablets. Because of the predominance of Android, tablets feature more recent software than mobile phones on the average.

Table 1: Age quantiles (in years) of mobile operating systems used on tablets, with corresponding version baselines for the 90% traffic quantile.
OS vintage Android iOS baseline for 90% traffic
Quantile 90% 50% 90% 50% Android iOS
Africa 4.0 2.4 3.9 1.2 3.0 7.0
Asia 4.0 2.4 3.3 0.6 4.0 7.0
Oceania 3.9 2.3 2.1 0.5 4.4 7.0
South America 4.2 2.4 3.9 0.5 4.0 7.0
North America 4.3 2.3 2.2 0.5 4.1 7.0
Europe 4.1 2.4 2.4 0.5 4.1 7.0

The baseline gives the minimum set of backwards compatible OS versions required to cover 90% of the traffic, and is therefore relevant to an organization maintaining an existing application. A firm launching a new app in Summer 2015 would have had to release it for iOS 8.0 or higher to comply with certification rules imposed by Apple from June onwards. In this situation, pushing back the Android baseline to 2.2 in Europe and 2.0 in North America, and throwing Windows RT 8.0 into the mix achieves a 90% coverage in those regions; in the rest of the world, no adjustment is sufficient – such was the backlog of users who had not yet upgraded from iOS 7.x.

When releasing a completely new app on the most current iOS and Android versions (resp. 9.2 and 6.0 at the time), with only forwards compatibility as a requirement, how long would it then take before 50%, resp. 90% of the users can effectively run it on their terminals? The answer is given by reversing the interpretation of the leftmost columns: in North America, for instance, it would take 0.5 years to reach 50% of the iOS market, and 2.2 years to reach the 90% mark. With Android however, 2.2 years are not even enough to cover 50% of the traffic: 2.3 years are necessary – and it lasts as much as 4.3 years before reaching 90%. The time constraint on market reachability is therefore set by the migration rate of the Android installed base.

Considering that only iOS imposes a restriction on the baseline, what would be the delay if one published an app backwards-compatible with Android 4.1, but running only on the newest iOS version (i.e. 9.2) at the end of 2015? The answer can be deduced in the same manner. Thus, 0.5 year suffices to cover 50% of the traffic in the North American iOS segment, and 2.2 years for 90% – and therefore to complete the desired coverage for the entire tablet market, since backwards compatibility with version 4.1 already caters for the Android market adequately.

As a final scenario, what if one developed an app backwards-compatible with iOS 8.0 and whatever Android version as originally set (i.e. 4.1 in North America)? This configuration ensures immediate coverage at the 50% mark for iPad users everywhere. The values for the 90% traffic quantile are not tabulated to avoid clutter, but they are trivial to compute: it is one year in every region.

Device testing

Entries in table 2 are derived from the ten most popular terminals by applying the same procedure carried out for mobile phones. Constructing the “global” test pool basically amounts to acquiring a couple of new tablets annually and working with the set accumulated in the past five years. A comparison with the entries for 2Q2014 shows that a test pool constructed in this manner remains quite stable over time.

Table 2: Device test pools derived from top-ten usage statistics.
Vendor Global 2Q2014 Global 4Q2015 Africa Asia Oceania South America North America Europe
Apple Air 2 Air 2 Air 2 Air 2 Air 2 Air 2
Air Air Air Air Air Air Air Air
4 4 4 Mini 4 Mini 4 Mini
2 2 2 2 2 2 2 2
Lenovo S6000l-F
Samsung Tab 4 10.1 Tab 4 10.1 Tab 4 10.1 Tab 3 lite Tab 4 10.1 Tab 4 10.1
Tab 3 7.0 3G Tab 3 10.1 3G Tab 3 10.1 3G Note 8.0 Tab 3 7.0 Tab 3 10.1 3G
Tab 2 10.1 Tab 2 10.1 Tab 2 7.0 Tab 2 7.0 Tab 2 10.1
Tab Tab Tab
Vodafone Smart Tab 3G Smart Tab 3G

Given the data on OS vintages, it is no surprise to find old devices in the test pool. Just as with OS versions, we can appreciate the information retrospectively or prospectively: in 4Q2015, a website or app had to work flawlessly on a 4.8-years old iPad 2 or a 5.2-years old Galaxy Tab. Four and half to five years from now, a future instance of a website or app will have to work flawlessly on a brand new (at the end of 2015) Samsung Galaxy Tab S2 or Apple iPad Pro.

Concluding Remarks

Market reports usually delve into the percentage distribution of software versions for various mobile platforms of interest. Mapping those percentages to durations provides an equivalent, directly operational input for product managers to shape their delivery roadmaps – assuming of course that neither OS market shares, nor OS upgrade rhythms shift appreciably compared to their historical record. Whether expressed as the length of time during which backwards compatibility must be guaranteed, or the delay before the installed base is able to execute a novel app, the lesson is sobering: this may be, and with Android it definitely is, a matter of years. Without such diachronic aspects, the absolute market share of a software platform does not give a faithful indication of market reach.

Furthermore, contrarily to the widespread perception that people replace their mobile devices biennially, tablets and handsets alike are remarkably long-lived, with popular models exhibiting continued high usage years after their first commercial availability. Hence, developers cannot presume that the installed base is essentially made up of recent terminals with modern hardware and an up-to-date software platform.

The statistical evidence and constraints imposed by app store administrative policies point to Web technology as the most adequate basis for mobile services intended to be swiftly adopted by an overwhelming proportion of end-users. Well-established methods render a website compatible across browser versions (progressive enhancement), with proxy-based browsers devoid of usual scripting capabilities available on client software (graceful degradation), and with entry-level and legacy devices featuring restricted or obsolete software (server-based content adaptation).

On tablets, a Web-based approach looks even more appealing, since their fairly large displays are very well-suited for responsive website design. Apps take over for applications requiring complex user interactions, like multimedia e-books. On mobile phones, the Web should logically remain the tool of choice to deliver universal services on multiple form factors and device generations, leaving apps as the ideal implementation for device-centric programs like games, and for innovations, such as augmented reality, taking advantage of the wealth of embedded digital sensors.


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.

Let us assume that we want to provision an app-based universal service, i.e. one that runs on terminals representing at least 90% of the mobile Internet traffic. From table 1, we read out that 90% of transactions in Europe originate from devices running an OS version that is at most 3 years and 6 months old. In Africa, such a universal service would have to support all software platforms dating as far back as 5 years ago!

Differences within regions are also striking. Fast product renewal cycles promoted by operators show up in a median OS version of about one year in North America and Europe, even less in Oceania. However, the 90% quantile itself is a substantial multiple of that duration, signalling a skewed distribution with a long-tail of devices running old software reaching to early variants of Windows Mobile and Symbian.

The minimal sets of platform variants catering for 90% of the traffic are also listed in table 1. Clearly, in developing countries mobile phones are not fashionable gadgets replaced every year or so, but costly investments that people hold onto for as long as possible. In those low-income regions, developers must rely upon the mobile Web or even simpler technologies such as SMS to offer Internet services on mobile terminals. Apps are not a viable approach there – all the more so since the above statistics exclude traditional feature phones that are not app-capable. Even in wealthier countries, ensuring 90% market coverage implies supporting all iOS releases since version 7.0 (the latest one being 9.3 as of this writing) – overturning the established pattern of iPhone users swiftly migrating to an up-to-date Apple software platform.

Table 1: Age quantiles (in years) of mobile operating systems in use, with corresponding baselines for the 90% traffic quantile for mobile phones.
OS age (years) OS versions covering 90% traffic
Quantile 90% 50% Android Blackberry iOS Windows
Africa 5.1 2.2 2.3 7.0 7.1 8.0
Asia 3.6 2.2 4.0 7.1 8.1
Oceania 2.6 0.8 4.2 7.1
South America 3.6 2.2 4.0 8.3
North America 3.1 1.1 4.2 7.0
Europe 3.5 1.1 4.0 7.1

Compared to the situation reported in the very first MOVR issue from 2Q2014, we observe that the OS requirement to achieve 90% coverage has barely budged in Africa, that in all other regions the Android baseline set at version 2.3 moved to 4.*, and that support for Windows is no longer necessary to attain the desired coverage in Oceania and Europe.

Crucially, those computed baselines are valid only for apps programmed long ago and minimally maintained ever since. An entirely new, or an upgraded app submitted to the Apple appstore during Summer 2015 had to be implemented with iOS 8 for certification. The impact of this policy constraint can be handled in two ways: immediately maintaining the 90% coverage requires the introduction of Windows 8.1 and 8.0 into the OS mix of Europe and Oceania respectively, pushes the Android baseline back to 4.1 in North America, 2.3 in Asia and Oceania, and 2.2 in Africa. The alternative is to wait six months (Asia, Europe, Oceania) or one year (Africa, North America) while iOS users shift to version 9.*, progressively regaining the 0.6% to 3.9% market share (depending on the region) accruing to iOS 7.*.

The lesson is clear: to provision universal services, ensure a rapid market ramp-up and achieve a comprehensive coverage for a large variety of terminals over long product life-cycles, the mobile Web remains the tool of choice. Advanced games for top-of-the-line hardware, bespoke intranet clients, specialized e-commerce sites, or disposable promotional apps must satisfy very different requirements, and in such cases apps are justifiable. Nevertheless, supporting apps on software platforms launched several years ago may become untenable for small software houses. Many apps interact with a server to fulfill their function; even if the client software remains unaltered forever after it is released for a specific OS version, supporting it means keeping changes on the server backwards compatible: refactored server APIs, restructured data formats (including lexical properties and semantics of data fields), security protocols and cryptographic algorithms.

Device testing

In a highly fragmented terminal landscape, validating the functionality and usability of an Internet service against enough end-user machines is a challenging task. Once more, we analyse the statistics from MOVR to answer the question “How large and varied must be the pool of test devices to exercise a mobile Web site adequately?”

The MOVR dataset lists the ten smartphones and feature phones with the greatest presence on the mobile Web in each region, as well as their individual share of the traffic. Clearly, no reasonable number of individual models covers the 90% traffic quantile; instead, one selects a sample that is representative of the handset mix.

We construct a test pool by delimiting yearly periods – starting from 4Q2015 till 1Q2015, then 4Q2014 till 1Q2014, and so on – retaining, for each software platform (Windows, iOS, Blackberry, etc), the most popular terminal released during each such interval. In a second stage, we consolidate the samples drawn for each region into one global pool by choosing, for each period and platform, the model that achieved the greatest popularity in any region (rather than across all regions); this procedure promotes diversity by catching particularly successful regional best-sellers. The suggested samples reach back 4 to 6 years (and even longer in Africa) as shown in table 2; the global set was slightly adjusted to reduce redundancy.

The enduring domination by the iPhone and Galaxy ranges is expected, and the Asian predilection for phablets perceptible; fortunately, the sheer success of Motorola handsets in Latin America allows a departure from the otherwise overwhelming Samsung offering. After the Lumia 520 persistently held a place in the top ten since the very beginning, a Windows presence is now completely gone. The lack of continuity in model type and vintage from 2Q2014 to 4Q2015 regarding Symbian and Blackberry indicates that both platforms are on the cusp of disappearing from all top-ten lists, most probably in 2016. The quartet of Nokia S40 phones provides the basis for testing interactions via numeric keypad, half-QWERTY keyboard, and touch-and-type mode – a relevant requirement for adaptive mobile Web sites that must cope with various input methods, not just different display resolutions and CSS versions.

Table 2: Device test pools derived from top-ten usage statistics; a combined test pool is shown and compared to the one derived from figures for 2Q2014.
Vendor Global 2Q2014 Global 4Q2015 Africa Asia Oceania South America North America Europe
Apple 6S 6S iPod Touch 6
6 6 6 6 6 6 6
5S 5S 5S 5S 5S 5S 5S 5S
5 5 5 5 5 5
4S 4S 4S 4S
4 iPod Touch 4 iPod Touch 4 iPod Touch 4
HTC Sensation
Motorola Moto G2 Moto G2
Moto G Moto G Moto G
Droid Droid
Nokia Lumia 520
Asha 311 Asha 210 Asha 210 Asha 206
C2-00 Asha 201 Asha 201 Asha 203 Asha 203 Asha 302 Asha 302
C1-01 X2-01 X2-01 X2-01
C3-00 C3-00 C3-00 X2-00 C3-00
E71 E71
RIM Z10 Z10
Curve Torch Torch
Samsung J1 S6 S6 S6
S5 S5 S5 S5 Grand Prime S5 S5
S4 S4 S4 S4 S4 S4
S3 Note 2 S3 Note 2 Y Duos S3 S3
Sony PlayStation Vita PlayStation Vita

In practical terms, the global test pool is basically formed by procuring an annual average of three or four mobile phones, picked from the most used models according to MOVR statistics. All such devices over a 5 years time span constitute the minimum set for checking that a Web site operates correctly with the installed base of mobile phones – the indispensable hands-on, live verification that cannot be satisfactorily accomplished with emulators.

Concluding Remarks

Performing quality assurance with five years old devices that were “hot” in their time, or maintaining a generalist app on multiple operating systems across several years match the experience of veteran mobile developers. The novelty is that the statistical basis provided by MOVR enables us to determine exactly which OS versions to support, and which terminals to test with, instead of relying upon intuition; in other words, it allows evidence-based requirements planning during mobile development.

Of course, although quite rich, MOVR data are aggregated at the level of continents, hiding frequently stark disparities amongst geographically close countries. Thus, Wiko is a major vendor of low to mid-range smartphones in France – but has only a fledgling presence in neighbouring countries. Though economically and culturally quite close, Switzerland and Germany have quite different distributions of market shares relative to iOS and Android. What was extracted from published information and highlighted in the present article constitutes therefore a first step.

The long tail of handsets running outdated software entails a consequence: servers must do some heavy lifting for device detection and content adaptation. It is not a terrifically clever use of wireless bandwidth to download a Javascript framework onto a terminal only to ascertain that no amount of polyfills and DOM wizardry is going to turn a low-end smartphone from yesteryear into a device capable of interpreting custom tags, firing up service workers, and reacting to Web push notifications. Such situations are better handled by sending a Web page tailored for the target device right away. Combining client and server-side techniques is the appropriate approach to tackle device diversity, and this also means that traditional infrastructure such as device description repositories will continue to play a central role in mobile service delivery in the foreseeable future.

Finally, what about tablets? They do deserve an investigation – in a separate article.


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:

Adding WURFL to Ektron

The use of WURFL is subject to a license. More information on offered licenses and pricing are available at The license grants you access to the Customer Vault, as shown in the figure below:


Screenshot from 2016-03-03 16:07:32


By clicking on View Account you will be redirected to the page that contains links to the WURFL binaries and WURFL Snapshot files.


Screenshot from 2016-03-03 16:09:31


The WURFL framework is made of two main parts:

  1. WURFL Snapshot


The WURFL Snapshot contains the information about devices that would let your Ektron code to serve intelligent markup to requesting browsers. The data is available in two formats: ZIP and GZ. From an API perspective there is no difference at all between the two formats. Choosing one over the other is a pure matter of preference. You do not need to download both files—either ZIP or GZ would work. The downloaded file, whether GZ or ZIP, must be copied to the App_Data folder of your Ektron installation.

Note: You may still have an old version of the web_browser_patch.xml file lying around. This file was used to keep the desktop browsers in the past, however, it was integrated into the main wurfl.xml. Please make sure you have removed the web_browser_patch.xml file

NOTE An updated version of the WURFL Snapshot is released weekly on Sunday night. In case of significant improvement to the data, however, out-of-band updates are still possible. You are responsible for getting fresh files and updating your App_Data folder. There is no strict need to apply updates on a regular basis; that is mostly up to you and updates can be scheduled at your convenience. The link for downloading fresh files is made available in your View Account page or you can automate the process.

The other part is the WURFL API which consists of two binaries:

  1. Wurfl.dll
  2. Wurfl.Aspnet.Extensions.dll


Go the Customer Vault then click on ‘File Management’ to download your files. Here is an example:

Downloaded binary files must be copied to the Bin folder of your Ektron installation. The Customer Vault lists all of the most recent releases of the WURFL library. In general, you should pick up the most recent one.

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!

Growing Device Intelligence From The Cloud

Since our inception back in 2011, we had a vision for device intelligence from the Cloud. Early on, we launched our WURFL Cloud product. It offers a client (which we have recently open-sourced – see here) that provides easy access to an always-updated WURFL DDR (see video). Part of having a reliable and fast Cloud service meant having hosted operations around the Globe. We currently operate in several POPs. And the service has grown very steadily.

In 2014, we launched our WURFL.js service. Using one snippet of JavaScript, web developers dip into our Cloud-based DDR and get back basic device intelligence information. To say that this service has been a success is a big-understatement. We now receive over 1 billion requests per month!

And there is more to come!!

We are constantly looking at ways to improve reliability and performance for our commercial customers. We have our own special requirements and have grown to a scale where it makes sense to invest in our own infrastructure at data-centers. Luckily, with our headquarters in Reston, VA, we have access to a premiere supply of world-class data centers to choose from. In fact, Ashburn, VA is known as “Data Center Alley“. We now leverage hosting infrastructure at a specialized facility known for one of the world’s most redundant, distributed, and scalable power delivery architectures (they call it “2N+2” with a 100% Availability SLA), at RagingWire Data Centers. Here are some cool pictures of our racks.

  • Categories

  • Recent Posts

  • Tags

  • Monthly Archives