Skip to main content

Mobile Browser Concurrency Test

By Jason Grigsby

Published on April 28th, 2008

Topics

We need your help for a research project. If you have a phone that has web access, please go to https://cloudfour.com/mobile/ to test the number of concurrent connections your phone makes. Your phone’s browser will need to display images for the test to work.

We’ve also set up a SMS keyword to make it easier to get to the test url. You can simply text MOBILETEST to 41411 on your phone, and you will receive back instructions on how to test your phone.

Please share this test with your friends and colleagues. We need as wide a range of mobile devices and browsers to test as possible to build a comprehensive database. We are interested in both smart phones and regular phones.

As we’ve moved from web to mobile development, we’ve found it difficult to find detailed information about the browsers on various phones. There are some good sources of information including Detect Right, Device Atlas, UAProf and the open source WURFL Project. However, none of these sources have exactly what we were looking for.

In particular, we’re keenly interested in the factors that make web pages load and render quickly. We’ve seen how optimizing web pages for performance can both make your customers happier and save large amounts of money on bandwidth and infrastructure.

With mobile devices, the speed of web pages is even more important given bandwidth, processor and memory constraints. Yet, for those trying to take advantage of the techniques promoted by Yahoo’s Best Practices for Speeding Up Your Web Site, it is nearly impossible to find how mobile browsers differ from desktop browsers.

That is why we developed the mobile browser concurrency test.

To our knowledge, this it the only public test that attempts to determine the number of concurrent http connections by observing the behavior from the server instead of the client. This is useful for any browser, but it particularly useful for mobile browsers where it is more difficult, if not impossible, to implement client-side network sniffers (which is the other way of observing the number of connections).

The test collects quite a few pieces of interesting information, but we’re looking in particular for three pieces of information:

  • What is the number of concurrent http connections that the mobile browser supports both per domain and overall?
  • Does the mobile browser support gzip or other methods for reducing the size of pages?
  • Does the mobile browser support caching if you set the Expires header far into the future?

We’re also collecting some other useful http headers and combining it with WURFL user agent information on the backend to help us when we start processing the results. We’re going to look for any interesting patterns in that data, but the main purpose is to gather the three items above.

We will publish the results of our tests under creative commons so that all mobile web developers can benefit from the information. We will be presenting our results at Web Visions 2008.

We’re also exploring how this data could be contributed to the user agent databases like WURFL.

Designing the concurrency test was a difficult challenge. In order to have the test work for as many mobile browsers as possible, we needed to support XHTML-MP 1.0 (WAP 2.0). XHTML-MP does not support javascript which meant that all of the testing needed to occur on the server.

The basic test works by delivering a XHTML-MP page containing 64 images distributed equally across 4 domains. When the first image is requested by the browser, the server opens a connection and holds it open without delivering the image. It waits 15 seconds to see if any other image requests come in. As each image request comes in, the counter for the appropriate domain is incremented.

For those interested, we’ve provided a detailed description of our methodology.

There are many people we’d like to thank for their help or inspiration in making the test possible. First, we’d like to thank Andy King for his wonderful book on web site optimization which first piqued our interest in the topic back in 2003. We’re indebted to Yahoo!’s Exceptional Performance team for publishing their groundbreaking work on web page performance.

Steve Souders formerly of the Yahoo! Exceptional Performance Team and now at Google has been the leader in getting people to pay attention to browser performance. He also provided helpful feedback on our test for which we are thankful.

We’d like to thank the many people who we roped into testing via Twitter. Special thanks to Aaron Hockley, Michael Richardson, and Charlene McBride for their BlackBerry testing.

Finally, we couldn’t have completed the project without Jon Maroney from Free Range Communications who loaned us a BlackBerry so that we could find the most obscure of BlackBerry browser bugs. And our own John Keith who did most of the heavy lifting on the programming. John’s adventures included calling someone to change code while he was at an AT&T store so he could test using the specific BlackBerry model that was giving us so much trouble.

Comments

Josh Bancroft said:

I figured you’d get plenty of testers using iPhones, so I didn’t bother with that, but I did just run the test using the web browser on my Amazon Kindle, in both “Default” and “Advanced” modes. Hope it yielded some useful information! 🙂

Michael(tm) Smith said:

I suspect you are going to find (if you haven’t already) that this method is not going to be usable in some carrier networks because the browsers on devices in those networks rely in part on proxies operated by the carriers — and specifically, on proxies that do certain kinds of image manipulation.

I live in Japan and the KDDI/Au handset I use here has two browsers on it: One is a version of Opera 8.6, and the other is v6 of the Openwave browser. Both of them rely on proxies, and I think the same is true for preinstalled browsers on handsets for other carriers here (DoCoMo, Softbank, and Willcom).

Jason Grigsby (Article Author ) said:

Hi Michael,

Yes, the proxies are going to be challenging. We’re actually looking for them in the apache logs. It was one of the notes we made in our methodology document about the potential short-comings of this way of testing.

So we recognize that as a problem and are going to try to correct for it when we analyze the data.

Thanks for testing and for the information on Japanese handsets.

Mario Zorz said:

Hi Jason,

I wonder what results are you expecting from the actual majority of handsets. As you must already know, most mobile traffic happens to be handled by the wap gateway in the operator. So basically what you see on your servers (where your test pages are hosted) is the behavior that the wap gateway has about fetching URLs in a page, not the actual phone’s. Let’s assume a phone normal browser does open several concurrent connections, all of them will hit the wap gateway, who will consider doing whatever is best for handling overall traffic – not just this specific phone’s requests. So the point is, the actual phone’s bejavior is obscured by the existence of a wap gateway in the middle. Felt the need to clarify this, wap gateway and proxies to a minor extent is IMHO a major short-comming for this kind of tests. It will only work with smartphones and networks that allow phones to reach the internet directly, rather than actually normal networks (every operator has a wap gateway and most traffic is handled by such network element).
Please kindly reply, I’m intrigued. marionetazorz at yahoo dot com.

Matt said:

Good site.I like it.

In today’s world you have a number of choices to make: what device should your application use, what operating system, what networks will be relied on? And the list only keeps growing. Why not make things simpler?

Mobiquest′s Mobile Test Centre offers mobile application and testing services to simplify the testing needs of applications developers, service providers and handset manufacturers.