Krzysztof Ziemianowicz About the Author

Why Page Size Matters even more for Mobile Web Apps

“Mobile” and “Web” sound like a perfect match, but reality often shows that these two trends form opposite forces. Recently we had an interesting engagement with one of our customers where we found how easy and dangerous it can be to inadvertently spoil end-users’ experience with mobile web application by forgetting the practical limitations and consequences of web page size, which quickly get heavier with expansion of the application functionality.
Last month, one of our customers asked us to help them find ways to diagnose why a mobile banking application that they rolled out – was slow compared to the regular browser web application. Customer already knew that the mobile web application was slow, and business owners were disappointed by this known fact that was easy to verify experimentally by anyone having a smartphone and account at the bank (and all bank employees have it). During status meetings, typical explanations were discussed over and over again: mobile devices connect over slower networks, mobile devices are less capable than desktops and it is just how it works, and so on – with no conclusion and no action plan

It is tempting to just assume that mobile applications have to be slow, especially since contrary evidence can be found. Gomez Benchmarks for example, published by Compuware (http://www.gomez.com/us-banking-web-and-mobile-site-performance-indices/), can be used to make a comparison like the one shown here, which just shows that average mobile banking applications are slower than desktop applications all around the world

Load Times of Mobile Web Banking Apps are slower than their Desktop Browser Apps

Load Times of Mobile Web Banking Apps are slower than their Desktop Browser Apps

However, our customer has always been challenging assumptions, including application performance paradigms, and this time was no different. We agreed to have a look at this application with a planned proof-of-concept for extending the existing agentless end-user experience monitoring into deep transaction monitoring within the data center.
A 15-minute walk-through the existing performance overview reports for desktop web and mobile web users revealed the root cause of the problem. First we confirmed that page load time delivered to desktop and mobile web users differs by more than 100%, and we confirmed that data center response time is not a problem:

The request for the Mobile App (wap/login.do) took twice as long as for the Desktop App (old/login.do) showing time spent on the Network for the root cause of this

The request for the Mobile App (wap/login.do) took twice as long as for the Desktop App (old/login.do) showing time spent on the Network was the root cause

This simple illustration of server versus network time breakdown of the login page reveals how much time during page load is spent on generating the response within the data center and how much time is spent transferring the response to the client. The “old” is the desktop web application; the “wap” is the mobile web application. Clearly, mobile web application users have to wait twice as much as desktop web users, and time is spent in response transfer over the network. We can also see how much time is spent by the client waiting for redirections that server is directing the client to take before final page content is served, but this piece is out of scope of this analysis. Let’s focus on the network time.
Network time is required to transfer data from server to client, and this time depends on two simple dimensions: bandwidth offered by the network connection and size of the page to transfer. Naturally, these two dimensions have their own influencers, but let’s leave this analysis for later. Let’s start now with checking the page sizes for desktop and mobile web applications.

The mobile web page has twice the size of the desktop application

The mobile web page has twice the size of the desktop application

Here comes the surprise: mobile web clients download more than twice as much data than desktop web clients – 109 KB versus 45 kB! This definitely was not expected, so we took one step deeper to identify what exactly was transferred to the mobile web user that took so much bandwidth.

Large image and script files impact page load performance on mobile web app

Large image and script files impact page load performance on mobile web apps

This waterfall chart illustrates a single mobile web page load for a single user – and it reveals what contributed to this page content. JavaScript and images form the bulk of that size, while even smart use of parallel TCP sessions to load content does not help – the truckload of data that has to be loaded to the mobile device is large and takes time.
By the way, the waterfall chart also reveals time that the mobile client needs extensive time to run the JavaScript and process the data – white spaces between horizontal bars indicate the time periods where client device is busy and does not yet open requests for more elements of the page. What the end user sees during these periods is the hourglass.
Designing mobile web applications requires a lot of creativity and effort, as mobile users tend to demand  a sleeker experience with the application than desktop users. Mobile devices provide narrower end user error margin, and end users set the expectations bar high, basing on their experience with state of the art iOS and Android applications they use every day on the same device. This requirement is so important that it can easily overshadow the old and simple relationship between page size and user wait time. More functionality requires more code and data on the client side, which requires more bytes to be transferred to the client, which in turn means longer page load times, and this negatively influences end-user experience.

Designing and Implementing Mobile Web Apps easily leads to huge payload impacing page performance

Designing and Implementing Mobile Web Apps easily leads and thereby impacting page performance

This is a vicious circle of the “sexy” web application design. Where is the balance between functionality and robustness? And overall, do you know what is the relationship between size, response time and user satisfaction? And do you control it?

Comments

  1. Excellent post Kris, demonstrating the impact of those issues mentioned in best practices, in real life.
    Indeed the issues of redirection, page/object size, combining images into sprites, using image URIs etc have clear impact on mobile end user experience. While it is tempting to think that the majority of impact on end user experience is inflicted by wireless carrier performance, that is really often not the case, as carriers continuously improve their networks (LTE and the likes), and many users these days work off wifi (many on tablets). So there is a lot of room for improvement using existing technology and a handful of recommendations.
    It’s interesting to see how the industry evolves to recognize new technologies such as hybrid platforms, HTML5, payments and services, sometimes forgetting about the basics: provide a good service to your customers. It’s been demonstrated how most end users expect mobile experiences to perform as well (if not better) than desktop. It would have been interesting to evaluate the business impact of the example you shown above: I’m sure abandonment rate was significant. Good functionality and performance should be top of mind to achieve the business success criteria.

  2. Carl Brothers says:

    Another thing to consider in the gaps of this waterfall, the system is looking to conserve battery power so it will likely turn off the radio if the appropriate timer is reached. Then spooling the radio up and getting connected again is even that much more painful for the end user…

Comments

*


eight − = 5