“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
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:
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.
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.
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.
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?