Cloud Four Blog

Technical notes, War stories and anecdotes

Mobile operating systems and browsers are headed in opposite directions

Some of the research we’ve been doing into mobile operating systems and browsers is now available as an article on O’Reilly Radar. Here is a short excerpt:

In 2006, two mobile operating systems controlled 81 percent of the market. This year there are 10 different smartphone operating systems.

Over that same period of time, mobile browsers have gone from many different proprietary rendering engines to the point where WebKit alone will power browsers in more than 85 percent of the smartphones sold.

Read the more of Mobile operating systems and browsers are headed in opposite directions at O’Reilly Radar.

BlackBerry Browser Bug

One of the more hilarious moments in developing the Mobile Browser Concurrency Test came due to an obscure and undocumented bug in the BlackBerry browser.

As we neared release of the test, we found that a certain set of BlackBerry devices was exhibiting odd behavior. While the user would never see the four rows of images in our test, both the test and that apache logs would report that the images had been downloaded.

After several hours of trying to figure out how our code had gone astray, we were getting desperate. So John drove to a local AT&T store. He found a BlackBerry to test with and called the office so we could change the code while he tested in the store. That phone call was one for the ages.

We stripped every line of code out of our test page until we had simply the html, head, body, and img tag. And the image still wasn’t rendering.

Finally, we removed the height and width attributes from the image tag and it finally worked. But this made no sense because we had an image tag on the other pages that had the height and width set and was displaying properly.

Further testing revealed that a bug in the BlackBerry browser: it will not display images if the height and width are declared and either is 4 pixels or less. Our test images were 4 x 4 squares.

Yes, it is that specific. Less than five pixels and the browser will download the file, but the image will never render on the page. In fact, the rules for when the image will and when it won’t display are even more specific:

  • If the image width and height are set to 5 pixels or greater, the image will render.
  • If either the height or the width is not declared in the attributes, the image will render.
  • If both the height and the width are declared in the attributes and either is 4 pixels or less, the image will not render.
  • The original size of the image does not matter. The only thing that matter is the size of the image declared in the html attributes.

If you have a BlackBerry, we’ve provided a test page to demonstrate the bug.

We don’t know how often people are going to build web pages for BlackBerries with images less than 5 pixels on one side, but we do know that if you do, you better be careful how you code the page or no one will ever see your work. We’re also certain that if BlackBerry wants to compete on the mobile web, it is going have to improve its browser.

Mobile Browser Concurrency Test

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.