NEW Grab our Technology Overview white paper
Date By Rohith Ramesh, Customer Success Engineer at PacketZoom Tags mobile services / optimization

Part 1: Set an Appropriate Caching Header

Which developer doesn’t want their apps to run faster and provide the best possible user experience? Having worked with hundreds of mobile apps, we have seen firsthand the dramatic impact that improved app performance can have on an app’s overall retention, engagement and monetization metrics. But as app developers focus on their core business, very few devote resources to building fast and efficient mobile networking capabilities -- even those who understand how vital fast and optimized apps are to their business.

In this series of blog posts I aim to point out some simple techniques to offer mobile app developers a DIY toolkit with mostly low-hanging fruits that, via small modifications, should boost the performance of their company’s app.

What is a Caching Header?

App assets such as images and game bundles get delivered with a header that defines how long it takes for an asset to be cached on the CDN (Content Delivery Network). Most commonly it is called the Caching Header. This header informs the CDN how long an asset should be cached on the CDN before it has to be re-fetched from the origin. We have seen developers use values ranging between 10 minutes to 10 years. Depending on the use case, I would recommend developers use the following guidelines: If the asset does not change quite often, it is better to set a high value. More often than not we have seen developers set low values for assets, even though they do not change frequently.

Here’s an example: For a retail application that features a “Deal of the Day,” the developer would probably be better off setting the “cache control“ header to one day so that for the entire day of the deal the users don’t have to go to the origin to fetch the deal’s images. On the other hand, for product images, it would be good to have really high values, such as a year or longer, since they don’t tend to change frequently.

There are countless mobile API-based services. From authentication, ads and payment API’s to price comparison and reporting API based services. The availability of these API’s made mobile app development much simpler, but this simplicity comes with a price.

Unlike images, game assets, videos and other type of static content, API’s are dynamic in nature and their content cannot be cached at the edge of the internet to increase download speed. Often times the result of an API call is customized per user profile, its location and the activity he/she is trying to accomplish. A user searching for a Mexican restaurant in downtown San Francisco will get a unique (non cacheable) search result.

There are three main challenges with existing API configurations that directly impact any mobile app performance:

How to define cache control values

There are three ways to define these values:

  1. Set Cache Control header: Use "max-age" or "s-max-age" directive in the response. Syntax: Example: Cache-Control: max-age=259200
  2. Expires header: This header contains the date and timestamp after which the asset has to be re-fetched from the origin. Example: Syntax: Expires: Example: Expires: Wed, 1 Oct 2017 07:28:00 GMT
  3. Etag: The ETag HTTP response header is the identifier for a specific version of a resource which is a key to the resource itself (example: MD5 hash). When the resource changes the identifier is also updated so that latest version is retrieved. Syntax: ETag: "" Example: ETag: "83424df55142klhaf8yf82148795d9f25f89d4"

Header examples for Apache and Nginx

The way to add the cache-control header depends on the server you are using. Here’s how to add for the two commonly used servers, Apache and Ngenix:

  1. Apache: The below code is the basic way to set the cache control header in the .htaccess file: Header set Cache-Control "max-age=259200, public" This code sets the object to cached for 259200 seconds. However, if you want to provide different max-age times for different file types you can do that as well.
  2. Nginx: Similarly, for Nginx servers, with the below you can set the expiry time: location ~* .(jpg|jpeg|png|gif|ico|css|js)$ { expires 14d; } This code caches the specified file format objects in parenthesis for 14 days.

  3. Persistent Connections. To avoid the “TCP handshake” overhead one could keep the connection open/warm and save a few round trips for each new request. This technique should be used carefully since overusing it will once again increase server load.

In conclusion, for any asset that doesn’t change often, it is advised to have a large value for cache-control, while assets that do change frequently it is better to have a smaller value. This will allow users to get the data from the CDN’s cache as opposed to go to the origin to get the content which will only increase the latency.

To get an insight into your own mobile app network performance, check out Mobile IQ - PacketZoom’s free forever Mobile APMO.

Share On:


comments powered by Disqus