User Experience of Cloud based Mobile Systems

Many readers of my blog asked in email: could i please compile the relevant research with references? Here you go: Today we want to focus on page load speed and latency. 

 

Faster cloud based web for mobile devices latency and how to accelerate by christian von reventlow v1

View more presentations from vonreventlow.

(Note the views represent my personal opinions and are not the views of my employer Avaya, detailed references are in the embeeded powerpoint presentation)

1. What are the page load limits for an acceptable user experience?

Google, Yahoo and others have researched this. The findings are:

• The time users are willing to wait before they navigate away from a page has decreased from 8 seconds in the year 2000 to 3 seconds in 2009. 2 seconds load time of a landing page decreases both the conversion rate and the total number of pages viewed by 10% - when compared to a 1 second load time.
• In addition users never get in a flow if the load time is too long. When a page loads in 200ms users click within 500ms. They experience that as a smooth flow. However time to the next click increases by 4 seconds when a page loads in 2 seconds.

Thus my view is: 2 seconds is the 2011 page load limit for an acceptable user experience. And i expect it to become less in the years to come.

2. How are various mobile web pages compare to the 2 seconds page loading speed limit? And are the cloud service providers giving you response times that allow to hit this limit/

There is a very limited number of mobile web pages with a load times below 2 seconds. In a recent review by blaze.io only 20% of the web pages were below this limit. Specifically a Google and a Microsoft Bing site were below this limit. This shows that both companies have taken their published research seriously.

I measured the actual latency of applications run on various clouds during 6 hours on a Monday morning on the east coast - resulting in 2.9 seconds to 4 seconds on wired network. Content delivery networks measured over 7 days showed between 6 and 12 seconds with an average around 8 seconds. Variability was quite large and reached 120% in an instance.

3. What is the right architecture to deliver your mobile web?

Typically LAMP (Linux, Apache, MySQL, PHP) or similar setups are used.

When designing the systems avoid sessions. Use cookies to store userID and login status. Scaling the webapps, image conversion, audio and video is easy - they scale horizontally. Use Hardware loadbalancers followed by SW loadbalancers as Wackamole, Poud, perbal or Apache with mod_proxy. And just add more servers.

Queuing helps for peak periods. However at some point you want to turn off the page as people learned from Macy's and JCPenny's web site performance at a recent Black Friday. People return later when the page is not available. But they are frustrated if the page is extremly slow and are reluctant to return.

Scaling the database is more tricky. As Carl Henderson puts it: Avoid it and go for a bigger box if possible. If you can't avoid it go for database replications. In most applications the read/write ratio is 80/20 or 90/10. That allows Master-Slave replication. Add memcaching to make scaling cheaper. A sideline cache as Danga will help.

When you need High Availability go for Master-Master replication, or to increase bandwidth Dual Tree architecture. Even more scale can get created with ringlike MySQL databaser clusters. Or by dividing tables into disjoint sets, federating by users or partitioning the database horizontally (Shards). Have a look on the Flickr architecture in the slide deck as an example of these methods.

4. What are the challenges on the device side and how to resolve them?

There are so many devices out there with so many different screen sizes. And so many different browsers with different capabilities. ..unfortunately on a global scale - IOS, Android, and Blackberry devices are a minority...

Coping with this variety gets done best by starting the design of a web page with a mobile only web page assuming a browser with minimum capabilities. Use a default stylesheet. And then enhance the view progressively using Javascript and @mediaquery. And adapt the content of the screen for the devices you want to support. WURFL is a database that contains hundreds of devices with their specific capabilities. Use CSS instead of Javascript for performance. And compress data. Plus - very relevant -send only data that will rendered on the screen.

Note that many PC oriented web pages have lots of data that never gets rendered. Find an example in the presentation where around 80% of the data transmitted to the mobile device never gets rendered.

Some tools help in the process. As an example: the open source phone gap tool allows to build Javascript based application that run on Apple's Ios, Android and Blackberry. And it supports WURFL easing supporting various screen sizes and resolutions.

Take Yahoo!'s 14 or now 34 performance rules and suggestions by people as Yibuu, Jason Grigsby, and Steve Souders to heart:

• Make fewer HTTP Requests. Don't forget that HTTP connections pipeline requests - slowing things down. And that according to the standard many browsers only support 2 connections per domain. Thus you want to use multiple domains to parallelize things. (and how many a browser supports varies from browser to browser...)
• Limit cookies as they get loaded with each request. Better only one. Or zero on some connections.
• Encourage caching with expire headers far out. And test if it works on your target browser.
• GZIP compression. Can take out up to 75% of transmission volume
• Javascript and CSS need to go external. And use only 1 each. Go for CSS and not for table layouts. And use CSS sprites - at least some browser support it.
• And minimize DNS lookups - as the are blocking till the DNS is resolved.

Testing your results is key. Tools like Yslow or Safar Web Inspector allow to understand the size of the individual elements of a page being downloaded, display a waterfall chart showing how time gets consumed and come up with suggestions on what needs to be done to improve the page.

Find some more suggestions in the powerpoint. And if you want to take things to the next level read Steve sounders article: Faster Webpages from the velocity-20090622.ppt. Just Google it.

5. And is the cloud making things better and simpler?

Unfortunately it does not look like it. Recent research shows that on average 8 hosts are involved in each transactions: Hosts delivering session information, search or CMS content - all inside of the firewall. And other hosts like Web Analystics, CDN content, Videos from a media server, ads from an adserver or information from a shopping card server.

And measurement shows, that more is required to be below the 2 seconds page load limit for a great user experience. At least for the majority of web pages out there. And even more so for mobile devices.

6. Conclusion

The quest for page load speed and low latency will continue. And many organization will need to continue to invest in optimizing their mobile web experience.

As a consequence all types of mobile applications - fat mobile apps, hybrid apps downloading data from the cloud and web based applications will be around.

It will be fun to see how HTML 5 with resident data will impact the game..


Let me know what you think. Questions? Suggestions?