Web Performance Calendar

The speed geek's favorite time of year
2015 Edition

Kenny Dits (@kenny_dee) works at M6Web (in France) for a broadcast TV company, he's passionate about performance and scalability issues and he/s responsible for the engineering team behind some M6 websites like 6play.fr.

What happens if one of our first of our third party libraries fails to load on our website?

This is a question we are now used to answering, thanks to incredible tools like WebPageTest and its genius request blocking feature, or even SPOF-O-Matic.

But, how do we answer the same question on native iOS or Android Apps? The goal is the same: how to be sure that our apps will load successfully or will not crash if one of the requests fails to load?

We will see how we can test that with a proxy tool.

There are plenty of alternatives (Fiddler?), but for the test, we will use CharlesProxy, which despite its blunt interface, has the big advantage of being cross-platform, is pretty easy to use and has all the features that we need. Beware that it’s not free software, but it has a free 30 days trial with all the features.

Proxify your tablet or phone to see the loading waterfall chart

Install and launch CharlesProxy on your computer. Connect your mobile and your computer to the same Wifi network.

Look for your computer IP connection to configure it as a proxy on your mobile. On OS X, go to “System Preferences” / “Network”. Select the “wifi” connection and grab your IP.

Go to your phone to change your wifi connection settings in order to add the proxy configuration with the IP address grabbed from the computer and the CharlesProxy port (8888 by default).

You should now load a website in a browser to confirm that CharlesProxy is able to view all the HTTP requests you made.

Measure All The Things

Go to the “Proxy” menu of CharlesProxy to uncheck the options that catch all the traffic from your computer “Mac Os Proxy” for example on OS X, and click on the trash icon to clean the session.

Also check the “Tools” / “No Caching” option, to make sure nothing is going into cache from one session to another.

You are now able to launch your app and see all the requests required by it. On the left side, in the “Structure” tab, a click on a domain name will give you some deeper information on the requests being made. Select all the domains in the left panel, and click on the “Chart” tab on the right panel to see the loading waterfall chart of your app. I know, it;s not as sexy as the WebPageTest one, but it’s useful nevertheless.

Extract the HAR

You could also export the HTTPArchive “.har” file with the “file” / “export” menu of CharlesProxy to use a tool like “HAR Viewer” or even HAR Analyzer to see a most advanced version of the Waterfall chart.

Be sure to uncheck the “Validate data before processing?” option to make it work.

Drag and drop the HAR file saved before in Har Viewer to obtain something more similar to the Network tool of your favorite browser:


We are now ready to test our app in normal conditions, but how can we check loading under bad network environment for example?

In “Proxy” / “Throttle Settings” you can simulate a 3G connection and define the “latency” you would like to test and see if there is “race condition” during the loading of your app.

Disaster case

Then we want to know if some calls are SPOF to the loading of our app (internal api calls or even 3rd party calls) and how the app deals with failures.

We will use Charles’ “Tools” / “Map Remote” feature to redirect all the calls to a domain or a file to the awesome “Webpagetest blackhole” made by Pat Meenan.

The blackhole URL “http://blackhole.webpagetest.org” is an endpoint to simulate the crash of a webserver. We’re not talking about the crash that correctly rejects all connections, but the one that keeps them alive until your browser or device hits the default timeout!

So you can now test your app by redirecting domains/requests one by one to the blackhole URL.

Launch and test your app after each modification and you will see if it is “fault tolerant”.

You will probably notice that the default timeout is huge on some devices (sometimes you’ll have to wait for 75 seconds!). Imagine the case in which those calls are synchronous during the launch of your app: it means that your users will have to wait this time before seeing anything or before being able to use the app if the endpoint behind those calls has crashed!

Here it is, you now have one method to test your native app in bad conditions to see if you are really fault tolerant, and to capture your app’s waterfalls and loading times.

This is just one solution, and I think there are many more. If you have an easier solution or one that doesn’t involve a commercial software, please share it.

So, how is your native app working when your:

  • An ad server is down?
  • Analytics are down?
  • An API is down?

Hope it works fine now 🙂