Mobile Application Performance: Caching
Posted in: Mobile, Performance Testing, Speed Up Tips   -   August 1, 2013

In today’s smartphone enabled world, there is a constant drive to supply more information and data to our end users. Customers want advanced features, data and knowledge, no matter the device or network.  In addition, they expect all of this content to appear quickly.  How do you as a developer ensure that your content arrives, and it arrives quickly?

When the internet was first introduced, users were on slow dial-up connections, and developers had to be very thrifty with the content delivered.  As computers have obtained higher bandwidth connections, thrifty techniques to squeeze the most out of every byte has been lost.  These new sites and features have revolutionized the web, but can cause many problems on mobile devices.  Mobile networks and devices are resource constrained by default (spectrum and congestion for networks; screen size and battery for devices), so being thrifty with your resources is a great way to make your application run as efficiently as possible. Yet, there is evidence that we as mobile developers are not heeding the thrifty ways of early web developers.

A recent study of wireless radio traffic found that over 17% of all HTTP traffic transmitted was duplicate content. As a thrifty developer, it behooves you to cache files on the device, so that you don’t need to download them again. When downloading a file, a connection must be established first (requiring multiple round trips), before the can be file downloaded and rendered.  Even without network congestion or poor coverage, it is pretty clear that if you can just access the file directly from the cache, you can bypass a LOT of latency.

AT&T has a free tool called the Application Resource Optimizer (ARO) that analyzes the traffic from your app on your mobile device.  It provides suggestions for ways to optimize the traffic you are sending based on more than 20 best practices.  Several of these best practices provide suggestions about caching.  Let’s walk through a couple of examples of how ARO can help you with caching in their app:

Here is the ARO visualization of a popular Android application that is not using caching at all:


In this graph, you can see that ARO is measuring all of the packets that are uploaded (Packets UL) and downloaded (Packets DL) from the device and is calculating throughput, bursts, and battery usage (RRC States).  In this trace, the mobile application was started at ~55 seconds, and ran until the app finished loading.  The application was stopped, and then restarted at around 170s.

What are we seeing here?  Well, both times the app was started, the radio was transmitting for about 25 seconds, and about 4.5 MB of data was downloaded to the device (you can see this qualitatively, as the areas under the throughput curves on the graph are roughly the same).  In the 2nd startup, nearly 100% of that data was duplicated from the first startup! By enabling caching on this application, the data usage and battery usage (from the radio) would be reduced.  But most importantly, the start-up time would be noticeably faster!

“A bird in the hand is worth two in the bush”

This 2600 year old saying also has huge implications towards caching.  When you add headers to your files, there are 2 common ways to check the cache: Cache-Control and ETags.

Cache-Control:  Specify a time (in seconds) when the file expires and should no longer be used locally.  Obviously, depending on the file, this should change.  The file containing local weather conditions might be cached for just 3 minutes, while the icon indicating “full sun” could be cached for weeks (since it does not change as often).  In this example, the image has a cache control age of 22 million seconds (about 7 years):


This file is the “bird in your hand”.  You will not have to access the network for this file for a very long time.

ETag:  An ETag is a unique identifier for a file.


Once the file is cached, your application must check the server to verify that the ETag is still current before it can reuse the file. This allows the developer to reuse file names while still forcing the latest version of the file to end users.  Utilizing ETags is still faster than downloading the entire file, but does require a network connection to be established before the file can be rendered from the cache.  To paraphrase our ancient Middle Eastern philosopher:  “I have a bird in my hand, but maybe the one in the bush is better.” Taking a more modern approach, this violates Steve Souders’ Rules for Faster Loading Websites: Rule 1 – Make Fewer HTTP Requests.

In conclusion, mobile developers need to think more like the thrifty developers of the early internet.  By simply turning on a mobile cache in your application, you can provide your users with enormous performance enhancements.  Use tools like ARO to verify that your files are indeed being cached, and to quantify the speed enhancements that you are building into your mobile app.

Doug Sillars (@dougsillars) has been a member of the AT&T Developer Program for the last 10 years. He currently leads a team of outreach engineers who are training developers in best practices for mobile performance. The tools and best practices developed at AT&T help developers make mobile apps run faster, use less data and less battery.

Tags: , , ,

  • jdorfman

    Great post Doug! It is scary that to learn that 17% of all HTTP traffic transmitted is duplicate content. I hope Developers take this into account when developing their next Mobile App.

  • Tim Rosenblatt

    There are a lot of mobile apps powered by Rails APIs.

    @Cloudspace just released Ettu which is a gem that can be dropped into most any Rails app and will improve ETag handling

  • Chris Ueland

    Nice Post Doug!