You have a sparkly new app. It looks great, and you are starting to see downloads from the various storefronts. But you begin to notice some troubling trend in your analytics. Many users use your app once or twice, but then stop. What’s going on? How can you optimize your application to retain users?
One huge factor in retaining users to your application is the speed of your app. If users perceive it to be slow, they may go elsewhere to get the same data that you provide. Well – how slow is too slow? A 2011 study shows that mobile web users will only give you 5 seconds to load your mobile website before moving on. It is imperative that mobile websites and applications are optimized to reduce loading delays.
At Google IO 2012, Steve Souders gave a talk on web performance, but I believe that his stats hold (and are probably even more important) for mobile. Yahoo.com found that adding a 400ms delay to their hompage resulted in 5-9% decrease in traffic. Google did the same study, saw a decrease in traffic, and interestingly – it took 6 weeks for these users to rebound and go back to using Google (http://stevesouders.com/docs/googleio-html5-201206
I don’t think users consciously perceive a 400ms delay, but they ‘feel’ this delay. What can you do to speed up your app? Tools like AT&T ARO (developer.att.com/ARO) allow you to measure and observe what your application is doing on startup. In order to optimize your application at startup:
- Minimize the number of files required before your app is usable
- Cache as many of these files as possible to further reduce the number of downloads
- Thread your downloads.
- Optimize your scripts
Let’s look at a popular application where the landing page has many images:
In this case the application starts at 8s and the page is done loading at 26s. That’s 18 seconds. What can this application do to speed itself up? I converted the pcap file from this ARO trace to a Waterfall diagram (http://pcapperf.appspot.com):
What you may notice is that there are 51 files being downloaded EACH time this application is started. At the speed mobile applications are updated, it should be possible to place some of these files into the application at download – avoiding the need to download them EVERY time the application starts up. Additionally, if 50% of these files could be cached, the second time the application is started up, the load time would drop even further.
The third example I gave is to thread your files. This means open up multiple simultaneous TCP connections to download many files at once. Some applications download all the files using one TCP connection. This is like standing in the grocery checkout line with only one register open. Only one person can be checked out at once.
6 images downloaded sequentially, versus 10 images loaded in threads. By threading the images, you can cut the download time by >50%.