Optimizing mobile network performance Part 1

What 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.

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.

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.

Stay tuned for the next installment of the series, in which we’ll explore the benefits of compression and its impact on network performance.

---

This content is made possible by a guest author, or sponsor; it is not written by and does not necessarily reflect the views of App Developer Magazine's editorial staff.

---