We need your help for a research project. If you have a phone that has web access, please go to http://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.
Why Test for Concurrent HTTP Connections in Mobile Browsers?
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.
What is Unique about this 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).
What are We Looking For?
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.
What Do You Plan on Doing with the Information?
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.
How Does the Test Work?
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.
Acknowledgements
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.
