Akamai Diversity

The Akamai Blog

Let's Give Users What They Want - Instant-on Applications

I have spent a lot of time investigating and writing about User Experience, especially in the world of mobile banking.  The conclusion is simple: users now expect instant performance, both on their desktop, and on their mobile device.  So why not give users what they want?  Let's give them instant-on mobile banking applications.
When I say "mobile banking applications", I mean any native Smartphone application used in the world of financial services.  This could be banking, brokerage and trading, insurance, investment advice, or others.  And my advice here applies to more than financial services - it applies to other areas as well, such as social media apps, commerce, media and entertainment, and gaming. In reality, instant-on should be applied to any app that you may use on your Smartphone.

Let me define what I mean by instant-on.  An instant-on application is one that immediately launches and displays the start screen, without any request/response over the WiFi or carrier connection.  This means that the startup is completely in the code of the application and Smartphone.  It is instant, in that the startup occurs entirely on the Smartphone.  Instant-on apps can launch in as little as under 100 milliseconds, vs. up to many seconds for apps that communicate back to a server upon startup. As I like to say, "It's only software, it will do anything we tell it to do."  Well, then why do developers tell their apps to "call the mother ship" just to launch?

Of the dozens of mobile apps that I have examined, less than  5% are instant-on.  For those apps that do make a request back to a web server, it's amazing to see what is being requested.  Sometimes it's a small configuration file, sometimes it's a lengthy disclaimer document (which does not even show up in the start screen), and other times is a huge waterfall, with over a dozen hostnames and dozens of objects.  In many cases, it has nothing to do with what is required for the start screen.

But perhaps most interesting (or puzzling, depending on how you look at this topic) is that this concept isn't new. Noted web performance evangelist Steve Souders lists "make fewer HTTP requests" as his number 1 rule for faster loading web sites. If we're doing it (or should be doing it) for "wired" web pages and applications, why aren't we doing it for mobile?

How to Examine Native Apps:
The first step to understand instant-on applications is to investigate the request/response flow from the app.  You can do this easily on a web page using tools such as httpwatch, but for native apps, it's not that simple.  To "sniff" a native app, you need to setup a network sniffer on your PC, and proxy your Smartphone through that PC.  You can then watch the requests from the native app, and the responses from the server back to the app.  It sounds difficult, but it's really quite simple. And once you have it setup, it takes only a few seconds to sniff a native mobile app.

I have detailed document that provides step-by-step instructions on how to sniff native apps, which I would be glad to share with you.  You can request a copy by posting a comment to the blog, or email me directly.  Just ask for the document "Taking the Mystery Out of Native Applications".

Of course, once launched, a banking app will require communications to a server, and there are many techniques that can be used to make those screens fast.  I have seen the good, the bad, and the ugly there as well.  But let's at least start off by giving users what they want, and make banking apps instant-on.


Will appreciate if you can email me the doc you mentioned.

"Taking the Mystery Out of Native Applications".
Robert M

Hi Robert,
I would be happy to. Please email your full contact information to me at ribolstr@akamai.com.