Cloud Four Blog

We’re pleased to announce the Mobile Wall Street Journal launched today. This application was developed by FreeRange Communications and the user interface was designed by Cloud Four.

The application is currently only available for Blackberry users. You can download the application for free.

Early reviews of the application have been positive. The Silicon Valley Insider says that of all of the applications that newspapers have released that “Wall Street Journal’s Mobile Reader is easily our favorite to date.”

As the interface designers, nothing could please us more than hearing them say:

The software, available today, is one of those tools that makes instant sense the first time you get your hands on it.

The vast majority of the hard work on the application was done by FreeRange Communications. It is their branded RSS reader that the Wall Street Journal selected. FreeRange asked us to help with the user interface design to make the application feel more like the WSJ.

The people at FreeRange have been good friends to us. They helped start Mobile Portland with us, made a diving save on our mobile concurrency test, and have been generous community members. It’s great to see them launch such a significant customer and announce their Mobile Publishing Platform.

It’s wonderful to finally get to share something we’ve been excited about for months. Congratulations to FreeRange and the Wall Street Journal!

I’m speaking today at the Velocity Conference in San Francisco. Back in 2003 when John and I spent weeks working on performance, we never thought performance would reach the point where a whole conference would be focused on it. It’s an amazing thing.

We’re going to be presenting our Mobile Concurrency Test and the initial results we’ve received.

For those in the Portland area, I’m going to be leading an informal session at this week’s Beer and Blog on how to optimize your blog for performance and why doing so is good for the environment.

More on how performance is connected to the environment in a moment, but first, the details on when and where:

Beer and Blog - Make Your Blog Load Fast & Save the Environment
Green Dragon Bistro & Brewpub
928 SE 9th Ave.
Portland, Oregon 97214
RSVP | Add to Calendar | Map

The Impact of Data Centers on the Environment

Everyone is aware that our ability to reduce our energy consumption is a key component to reducing the impact we have on the environment.

However, it wasn’t until I was asked to speak to the Storage Networking Industry Association (SNIA) at Storage Networking World last fall that I realized how important this is for those who run data centers.

At the time, I observed:

Several businesses are now being told that they cannot bring any more power into their data centers. The power company is simply refusing to provide them with more capacity.

In many cases, the cost of powering and cooling a data center exceed the costs of the hardware within two years.

The people in the storage industry get it. The SNIA has started the Green Storage Initiative to foster innovative ways of reducing power consumption in data centers.

The question is are those of us who are web developers doing our part? Sadly, no.

Web Site Gluttons

Web developers live insulated lives. We have broadband at our homes and our offices and it shows. We’ve stopped paying attention to the size of web pages.

Andrew King recently highlighted research showing that the average size of web pages has doubled since 2003. “Longer term statistics show that since 1995 the size of the average web page has increased by 22 times, and the number of objects per page has grown by 21.7 times.”

Source: http://www.websiteoptimization.com/speed/tweak/average-web-page/

In addition to the size of web pages, few sites are optimized to ensure that browsers cache the files and don’t request the same files repeatedly.

Steve Souders recently conducted a thought experiment on how much CO2 would be saved by optimizing the Wikipedia home page. He used the CO2stats.com estimate that “three minutes on a Web site generates three grams of CO2 - roughly equal to the amount one person generates by breathing for 4.5 minutes.”

Steve estimated that the optimization could save “5,000 kilowatt-hours per year or approximately 500-1000 pounds of CO2 emissions.”

Why Now?

I’ve been interested in web optimization for ever since it saved my prior company tens of thousands of dollars a few years ago. I’ve been speaking on the topic whenever possible and trying to help web developers understand how much benefit they can get by optimizing their pages and how easy it is to do.

A couple of weeks ago, I finally watched An Inconvenient Truth. At the conclusion of the film I started thinking about what more I could do. I’m getting a bike ready to use for my commute to work. I’m reducing the energy I use. I’m contemplating a vegetarian diet.

And I’ve redoubled my commitment to getting web developers to take site performance seriously. It saves money, improves the experience for your customers, and it’s easy to do.

Most importantly, if you care about global warming, optimizing your site is a moral imperative.

So come join us tomorrow at the Green Dragon to make your blog faster and reduce the energy it consumes.

A couple of weeks ago, I had the privilege of speaking at Web Visions on two topics that I am passionate about: mobile and web performance.

The presentation was entitled Going Fast on the Mobile Web. Included in the presentation is the first results from our Mobile Browser concurrency test and some of the conclusions we’ve been drawing from the test results.

The response from people who attended the session was positive:

Alsymer: Really enjoyed @grigs’ optimizing mobile session … most useful of all the sessions I’ve been to so far at WebVisions=

davemerwin:@grigs needs to do a workshop next year

mfriesen: @grigs mobile session was excellent. Much useful knowledge.

buchino: mobile web presentation was great… cloudfour.com guy (@grigs) knows a lot.

I was extremely pleased to hear that people enjoyed the presentation. I’ve been attending Web Visions for years and have seen both good and bad sessions. I was determined to make sure no one walked out of the room without learning something.

(As an aside, how wonderful is it to have feedback via Twitter for presenters to know what they’ve done right and what they need to improve on?)

Speaking at WebVisions alone would be remarkable, but something truly unexpected happened after the slides got posted online. They seemed to strike a cord with people. The presentation was selected as Slideshare’s Slides of the Day. It was featured on the O’Reilly Radar, Ajaxian and quite a few other sites.

A comment made during the presentation even made it to the top of Fast Company’s home page as their Big Idea of the Day.

To date, the slides have been viewed 9,598 times, downloaded 677 times, favorited by 69 people, and embedded on 47 web sites.

I’m very grateful and humbled by the attention the presentation has received. I’m most excited about the conversations that it has spurred. I’ve got much more to write about and share based on the conversations during Web Visions and after.

Thanks to everyone who attended the session or read the slides online. I appreciate you taking the time to take a look at what we’re doing and why we believe the mobile web is so important.

Here are the slides themselves:

| View | Upload your own

All of the slides for previous meetings of Mobile Portland have been posted on a Slideshare Mobile Portland group.

Last month’s presentation by Dietrich Ayala about Firefox for Mobile Devices also includes an audio recording of his presentation.

Cloud Four’s Jason Grigsby will be presenting at Web Visions 2008 this Friday. His presentation will focus on how to build fast mobile web pages and will cover some of the results from our recent mobile browser tests.

If you haven’t attended Web Visions before, we highly recommend it. It is a great conference at an exceptional price. This year’s keynote speaker, Jeffrey Veen, is one of our favorites. This is a must-attend conference.

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.

We’ve been asked by a few people if we can release the preliminary data that we’re gathering in our Mobile Browser Concurrency Test. So here you go: raw data from the mobile concurrency test.

And when we say “raw data,” we mean it. We spent most of our time fine-tuning the test in order to make sure that it was as accurate as possible. We didn’t spend much time building our our own view into the data because we knew we would always have time to work with the information later.

Therefore, the data view isn’t very polished and will probably only be interesting to those who are looking for specific details.

There are three things you can see in the raw data:

• An overview of all of the devices that have tested grouped by user agent and number of connections
• For any given device, you can click on the user agent string to see all of the times that device has been tested and the http headers that were requested.
• If the device was a mobile device, you can use the user agent string to query the WUFRL database to get more detailed information about the device characteristics

You’ll also get so see some of the anomalies that we’re investigating such as browsers that take too long to download the first image and thus are showing zero connections or the random instances where browsers request more concurrent images than they are supposed to be able to do.

We’re still planning on summarizing and publishing our findings. However, in the meantime, we hope you find the raw data interesting.

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.

Mobile Portland is this coming Monday, April 28th at the PSU Business Accelerator. More details and RSVP