Did you know that your application is not caching images by default? If your developers are coming from the world of web, they are used to having the browser do this work for them automatically.  However, in mobile, you have to explicitly turn on caching in your application. A recent study found that 17 percent of all mobile content consumed was downloaded in a duplicate manner, resulting in slower mobile applications, increased data usage for your customers, and higher server costs for you.

Why cache?  Well, caching data locally allows content to get to the end user faster.  It reduces the amount of data your app uses and reduces the battery drain of your application. Caching data is a simple way to speed up your app and save battery life. Further, since you are paying for servers and the bandwidth that the servers are sending down to your mobile application – you’ll even save money.  This performance improvement is an all-around winner!

What are you waiting for?

There are two common headers used for caching, and each behaves differently: Cache Control and ETag. I’ll do a quick description of how they work and then conclude with the preferred caching for mobile.

Cache-Control gives the age until the file is expired (in seconds).  For example, this file will expire in 1.43M seconds (about 16 weeks).  Every time a file is needed, the application looks for the file in the cache first.  If the file is there (and is not expired), then it is served immediately (this takes about 50-250ms in my testing). If the file is expired, it is re-validated on the server and either downloaded or served from the cache.  If the file is not present in the cache, the file is downloaded from the server.  In my test of a 105K file, loading from the cache took under 500ms, and loading from the server took 2-5 seconds. Cache loading in this case is 75-99% faster than download.  This performance improvement is one your customers will notice.

ETag: Each file has a unique ETag ID header.  When the file is to be served, the application first checks the existing ETag against the server to see if the files are identical.  If they are identical, a 304 Not-Modified response is sent.  If the file is changed, the new file is downloaded to the device. Note that ETags vary by server, so if you have a distributed server, you should not use them.

In this example, the application has the file in cache, but first uses a HEAD request to just get the ETag header to compare to the cache. Since the request is just for the header, the file is not downloaded.

This request took about 2 seconds to create the connection, get the request, and then process the image from the cache.  Since just reading the file takes 2-5 seconds, using an ETag is 0-60% faster than no cache at all.

So which is better?

Since Cache-Control cache retrieval does not need a network connection for validation, it is much faster than using ETags.  In the two examples above, loading an image from the cache with Cache Control takes under 221ms, and 2-3s when using ETags.

Performance research shows that HTTP requests had the biggest impact on reducing response time.  Based on this, they recommend that to reduce latency (for the Web), removing ETags is a good way to speed your applications.  If removing ETags speeds up applications on the Web, this speedup will be only accentuated on mobile.

In conclusion, any caching is better than no caching.  However, to take advantage of the speed and power savings that caching can provide, take advantage of cache control.

Come visit me at the AT&T Developer Summit in Las Vegas on January 7th at 3PM PST. I’ll be presenting a talk called, ” Turbocharge Your Mobile App,” where I can help you evaluate your caching success!

Have you tested your application to ensure that caching is correctly implemented?  Try AT&T’s Application Resource Optimizer to see if your application is caching correctly.