3 Fixes for Common Mobile Banking Performance Problems

In their relatively new role as mobile app and mobile web developers, banks are hitting many speed bumps — glitches, 404 errors, slow response times, and crashes that drive customers to frustration and sometimes to the apps of competitors. Resolving these is important as mobile banking usage continues to rise.

Experts identify several typical problems that crop up with mobile banking apps and sites.

1. Slow download times. A good metric for mobile app and mobile web performance is response time. Keynote Systems maintains an index for which it monitors page download times and transaction completion times for the mobile websites of several banks, brokerage houses and credit card companies. (The company also tracks banks' native app performance, but doesn't publish an index for them.) The average response time for these sites in mid-July was 15 seconds.

Fifteen seconds might sound reasonable, but user expectation surveys the company has conducted across a range of retail industries have found consumers expect page download speeds of four seconds or less on smartphones; two to three seconds on desktops. "That's a pretty big gap between user expectation and actual delivery," says Aaron Rudger, performance monitoring evangelist at Keynote.

Page download times depend partially on the performance of a user's network provider.

"A lot of companies look at the problem from exactly that angle and say 'it's out of my control, there's nothing I can do, therefore I'm not going to do anything,'" Rudger says.

But how an app is designed can still make a difference. A look at the fastest and slowest sites in Keynote's financial services index is instructive. The fastest is Charles Schwab, with an average response time of just under five seconds. The slowest is Bank of America, which comes in at just under 30 seconds.

The difference in the design of these two apps? The Schwab site contains only six page elements, whereas the Bank of America site has 58. Each page element involves a request to the web server, which slows the overall page download time.

"Charles Schwab has said, we know our users are on these wireless networks, are there ways we can create a page and experience that's optimal, knowing that wireless carrier network connections experience very high latency?" Rudger says. "They've made the choice to present a light page with a very low number of page elements on it."

Fewer page elements naturally means fewer features, a concept that may be off-putting to banks trying to compete with other mobile apps.

"The industry at large is trying to understand the tradeoffs, the appropriate balance of content and functionality against performance," Rudger says. "I think the sites that are asking that very question are leading the way. At the end of the day, if you can't connect to the website or download a page on your mobile device, regardless of how shiny and capable it is, that feature is not going to do you any good."

In addition to streamlining web pages, developers also can speed response times by limiting the number of redirects and lookups, which also contribute to latency.

2. Crashes. The typical crash rate for mobile banking apps and sites is about 5%, according to Bill Shipley, executive in Accenture Mobility Services.

Sometimes system crashes are outside banks' control. "When Apple moved away from Google Maps to their own map application, a lot of people didn't realize they were going to be changing, and that caused a lot of apps to crash," says Shipley. Many banks had the "find an ATM" feature in their mobile app mapped to Google Maps.

Other times, the fault lies within the bank's app design. Often when a bank releases a new app or upgrade, a new feature such as mobile check deposit doesn't work, and the daily crash rate will spike, as will complaints posted to the app stores.

Comprehensive app and mobile web performance testing is one way to avoid crashes. A best practice, according to Shipley, is to not leave application testing for the very end of the development cycle; it should be built into the overall process.

3. Glitches due to mobile device diversity. One challenge banks face as mobile app developers is the growing number of mobile devices, and operating system versions for some devices, they need to support, from Apple iOS to the many iterations of Android to the less relevant but still kicking BlackBerry and Windows Phone.

The multiple Android operating systems present a special challenge. An app written for Jelly Bean may not run well on Honeycomb, for instance.

And Google lets manufacturers customize the operating system, which leads to more variations. "Because Android is so widely dispersed and the most popular operating system out there, these manufacturers have to distinguish themselves in the hardware and the features they offer," says Rachel Obstler, senior director of product management at Keynote. "It's a competitive advantage to be able to customize the Android OS." Where one maker such as Samsung may support swiping, another requires key entry. Some Android devices have a physical keyboard, others don't.

Making an app display well on a plethora of screen shapes and sizes is not easy. "The Samsung Galaxy S4 has got a very large viewport, whereas the Nokia Lumia running Windows 8 has a much smaller viewport," Rudger points out. "The visual experience is going to be very different." A button may not show up, or appear only partially on the screen.

Actual performance varies by device, too. For example, different devices have varying cache sizes (the amount of memory the phone allocates to storing data for repeated use). If a website is built with the premise that there will always be 200 kilobytes of cache available, and the device has only allocated 100 kb for caching, performance will suffer.

And mobile device operating systems differ in their support for Javascript. "Some older versions of Android, like Gingerbread, don't play well with certain Javascript libraries," Rudger says. "A website using some of these libraries is not going to be able to access this content and your page might hang as a result."

A best practice to prevent such issues is to test on many devices, both emulated and real, says Obstler — emulation doesn't always mirror the way a device works in real life. It's not necessary to test on every device in the market, which would take a long time, but on a representative subset of operating systems and screen resolutions, she says. Another best practice is to write a script that works across devices, which can speed up testing across devices, Obstler says.

Better metrics and reporting can help with all these problems, Shipley says. Only about 40% of financial institutions have a mobile analytics solution, he says. The rest are either winging it or don't have a formal means of monitoring performance. Some banks only track metrics such as number of downloads or logins. Eventually they will want to measure the metrics that matter in terms of goals such as customer retention and customer attraction.