Posted on by & filed under mobile, testing.

With today’s metered data plans and intolerance for slow apps, mobile app users are very sensitive to excessive data consumption and underperformance.

Even a well-functioning app can have underlying inefficiencies, and a great way to fully understand your app’s data usage pattern is by running all its traffic through an HTTP proxy like Charles. When connected to the proxy you can complete tasks as a user would, to see exactly what’s being requested by your app, what’s being returned by the servers, and even the server response times.

Set up a Charles environment

(NOTE: Device and PC must be on the same Wi-Fi network)

On your computer:

  1. Download and run Charles
  2. Go To Help -> Local IP and write down the IP Address
  3. If you use SSL for your data requests:
    • Go to Proxy -> Proxy Settings -> SSL -> Check “Enable SSL” and add the host and port for your requests
    • You may also want to disable Desktop and web proxies from the Proxy dropdown so you can better isolate your app traffic

On your device:

  1. Install the Charles SSL Certificate on your device, visit one of these URLs on your device, and accept the security warning:
  2. Configure Device
    1. For Android: go to Settings -> Wifi -> Tap and hold wi-fi SSID -> Modify Network -> Show advanced Options -> Proxy Settings -> Manual
      • Server = IP address from Step 2
      • Port = 8888
    2. For iOS: go to Settings -> Wi-Fi -> (>) button for Wifi SSID -> Proxy=Manual ->
      • Server = IP address from Step 2
      • Port = 8888
    3. You might want to turn off cellular data to ensure all traffic is run through Wi-Fi/Charles Proxy

NOTE: If you quit Charles the device will have no connection until you undo the items in step 2b or 2c.

Fire it up

Launch Charles and switch to the “sequence” tab in the top window to see each call and status as they are made in real-time, including response size and duration. Click on a request to view details in the bottom pane including:  Overview, Request, Response & Summary.

Make sure you explore the options for the different data types. For example, if your response is an image, you can see the actual image and dimensions. If your app consumes JSON, you have a choice of a JSON Tree Navigator, or you can “copy response” by right-clicking the request in the top “Sequence” tab. Paste the results into something like for easy-to-read output.

I typically start with a fresh install of my application to ensure nothing is being read from the cache and that all data comes from the server, and then I start a new session. Here’s my list of some things to consider to ensure data transfer is optimized and the app doesn’t have to work harder than is necessary:

Things to check during app launch

  • Is your app making a reasonable amount of data requests to balance startup time and pre-fetching, to speed up “next pages”?
  • Is any request fetching more data than necessary?
  • Are the response times high due to server configuration or a poorly performing backend?

Things to check during app usage

  • Is there a common navigation path that is slow and could benefit from pre-fetching at launch?
  • Is data actually coming from the cache rather than initiating a new data request?
  • Is any tracking data being sent (e.g. Omniture, Google Analytics, or other third-party services), and if so is it sent properly ?
  • Are there any requests being made erroneously or repeatedly due to a coding error?
  • If you serve video, is the proper encoding/format selected? (Charles can throttle speeds to mimic wireless phone connections.)
  • Are images appropriately sized for the device?

More Resources:

Chapter 10. Secrets of High Performance Native Mobile Applications

Web Performance Daybook Volume 2


Comments are closed.