News

iPhone Users Moving to Larger Screens

For iPhone Users, Bigger is Better. Smaller is Not.

In the latest MOVR report, we looked at iPhone Screen size trends. We compared Apple’s new model releases, looking to see if there was a preference for size. Roughly, the iPhone SE is small (diagonal display size of 4”), iPhone 6S is medium (4.7”), and iPhone 6S Plus is large (5.5”).
Today, the “medium” 6S is much larger than its predecessor, the iPhone 5. We classify the iPhone 5’s 4” display as “small”.
The “medium” iPhone 6S is the leader in all countries, with over 15% of iPhone traffic in most countries.
The larger 6S Plus has gained over 5% share in the USA, Australia, Viet Nam. In most countries, it ranks ahead of the small iPhone SE by almost 2X.
While only released in March of 2016, the smaller iPhone SE does not appear to have significant share yet.

iphone screen size by country

iPhone Trend Shows Switch to Larger Screens over Last 2 Years

  • Usage of iPhones with a 4” display is on a downward trend (-7%). This is despite the release of the iPhone SE in March 2016.
  • The iPhone 6 and 6S, with 4.7” displays, grew 5% to end with 49%.
  • The larger iPhone 6 Plus and 6S Plus with 5.5” displays have added 4%, ending with 19%.iphone scren size trend Aug 2016

Are 3 Image Sizes Enough for Responsive Web Design Sites?

Are 3 Image Sizes Enough for A Responsive Web Site?

The answer is: if you care about mobile performance and payload, then you need a better solution than only 3 image sizes. We evaluated over 53 million requests for images from 1.6 million distinct urls (see our MOVR report). On average, it takes only 8 requests to surpass the need for 3 image sizes. Resizing to the standard 3 versions helps reduce the payload to 63% of the original. But if you automatically detect the actual device, resize, and compress to an optimal size, then you can save 84% of the payload. For image-heavy sites with a large amount of mobile users, this performance improvement could have a big impact on user experience and e-commerce conversions, potentially generating millions of dollars.
Blog-Payload-Savings-Automaticv3

Read More…

5 Steps to Add iPhone Models to Google Analytics with WURFL.js

Add iPad and iPhone Models in Google Analytics

Do you want information on specific iPhone models in Google Analytics? Ever wonder why Google Analytics can’t give you more detail about iPhones and iPads?  After all, an iPhone 4, iPhone SE, and iPhone 6S Plus are different phones representing VERY different markets. Wouldn’t it be great to drill down into that detail?

Now you can with 5 easy steps:

  1. Get a WURFL.js account
  2. Insert the WURFL.js script into your page
  3. Send the WURFL Device Capabilities to Google Analytics Custom Variable
  4. Set up Google Analytics to track WURFL Custom Variables
  5. Analyze the data and set up dashboards

iPhone Models in Google Analytics Read More…

Is Your Responsive Design Working? Google Analytics Will Tell You

[This article was originally published in Smashing Magazine.  We have updated the section on Universal Analytics to conform with change by Google Analytics.]

By

Add iPhone to Google Analytics

Responsive web design has become the dominant method of developing and designing websites. It makes it easier to think “mobile first” and to create a website that is viewable on mobile devices.

In the early days of responsive web design, creating breakpoints in CSS for particular screen sizes was common, like 320 pixels for iPhone and 768 pixels for iPad, and then we tested and monitored those devices. As responsive design has evolved, we now more often start with the content and then set breakpoints when the content “breaks.” This means that you might end up with quite a few content-centric breakpoints and no particular devices or form factors on which to test your website.

However, we are just guessing that our designs will perform well with different device classes and form factors and across different interaction models. We need to continually monitor a design’s performance with real traffic.

Content-centric breakpoints are definitely the way to go, but they also mean that monitoring your website to identify when it breaks is more important. This information, when easily accessible, provides hints on what types of devices and form factors to test further.

Google Analytics has some great multi-device features built in; however, with responsive design, we are really designing for form factors, not for devices. In this article, we’ll demonstrate how WURFL.js and Google Analytics can work together to show performance metrics across form factors. No more guessing.

Read More…

Get WURFL Release 1.8

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

What’s New in Release 1.8

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

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

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

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

Add ImageEngine To Your CDN Mix

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

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

CDN usage according to httparchive.org

CDN usage according to httparchive.org

Check, I have a CDN

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

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

Multiple CDNs

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

sites using multiple cdns

45% of sites use more than two CDNs

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

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

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

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

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

See how much ImageEngine can save your site:

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

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

3 Reasons Your Images Load Slowly

To summarize these approaches:

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

Read More…

Mobile Device Fragmentation and Proliferation

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

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

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

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

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

visualization (12)

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

Statistics on Internet Traffic – Tablets and Mobile Phones Compared

by Eduardo Casais – Part 2 of 2

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

Two mobile market segments

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

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

 

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

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

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

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

Read More…

What Statistics on Internet Traffic Teach Us About Mobile Development

by Eduardo Casais – Part 1 of 2

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

Insight From Data

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

APP development

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

Cumulative traffic distribution relative to date of operating system availability

 

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

Read More…

  • Categories

  • Recent Posts

  • Tags

  • Monthly Archives