I’m resuccitating this old artile to support some inbound traffic.

We know that the first practice to speed up performance of a site is to minimize the number of HTTP requests. The same should be true for mobile apps too, but the results I find from some of the apps I commonly use on my iPhone show that the apps have not paid enough attention to this practice. I used Charles Proxy for my tests. I can not vouch for the correctness of some of the headers reported by this proxy, but the common pattern I noticed is the number of HTTP requests they fire up is not small. This pattern has obvious impact on the user-perceived latency and even battery life.

Here is a summary.

Bing

Task: Search

• 1-n GET requests for auto-completing search string.
• One POST with XML for fetching search results
• A couple of POST requests for instrumentation — these are like beacon requests with zero length responses.

Google

Task: Search

• Seven short POST requests exchanging some application/binary content — not sure what their purpose is
• 1-n GET requests for auto-completing search string. The response is application/json, but the resposne is actually Javascript (and so the Content-Type should be `application/javascript’.
• Four GET requests to log suggestions. These are again like beacon requests with zero-length responses.
• One GET for search results

Mint

Task: Open the app

• 26 requests over TLS — I suspect that the number of requests depends on the number of accounts — now I know why this app is so slow on my iPhone.

Netflix

Task: Open the app

• One request over TLS, probably for some token exchange.
• One GET to fetch some config data
• One GET to fetch some policy related info
• One GET to get date-time from server (why not Date from a previous response?)
• One GET to get rental history, two GETs to get rental queue, two POSTs for ratings, one GET for account info, another GET config request, one GET for catalog, and a POST for some misc data
• A number of unconditional GET requests for static assets with expires set to a day later

Amazon

Task: Open the app

Just two POST requests with application/octet-stream encoded data.

LinkedIn

Task: Open the app

• One GET for the profile
• One GET for messages
• One GET for some alerts
• One GET for favorites
• One POST to report metrics

The order and number of these requests depends on the UI state of the app.

Facebook

Task: Open the app

• Six pre-flight GET requests — not sure what the purpose is — there is not much that I could discern from responses
• One request over TLS
• A POST multipart/form-data request with an XML response (falsely advertised as text/html) with some profile data
• One multipart/form-data POST request — the response is XML encoded within XML.
• A number of unconditional GETs for static assets — expiry set for a few months

Ignoring some funny use of HTTP, my key observation is that most apps are built on top of existing “APIs”. The APIs are providing access to different types of data, and the app is aggregating that data from the client (the phone) side. So, even simple actions like opening an app cause a number of requests from the client. All the apps I tested are branded and not built by third-parties and hence do have every chance to optimize the traffic.