redBus app was loading slowly in Peru and Colombia when compared to other countries. We found this using App Start up times on On-Device metrics.

While looking into Firebase Performance Analytics for clues, we identified that it was an API that had a larger latency in Peru and Colombia that caused the slow load.

Response times of a rest api in different geographies

In the image above, one can notice that Colombia, Peru have larger latency. The mitigation plan was to put up servers in LATAM. This would certainly bring down the latency.

Incident 2 — One of our metrics in Malaysia was going down:

One of our metrics in Malaysia was going down.

While hunting for clues we were able to see that an API was sending error responses to the mobile app. This happened when mobile phone numbers of certain patterns were put in as input. Analysing more into the API in more detail in FPM console helped understand the situation better. The API in fact was the problem. For arriving at this conclusion, FPM provided us with data that were previously hard to get hold of. The geography level segregation of api performances is a very vital piece of information.

Success Rates of a rest API across geographies

On Device Metrics :

1. App launch time reduction

We were able to reduce app launch time by 53 % on Debug build.

How did we measure it?

1. Xiaomi Redmi Note 4 device was used to measure the performance

2. The launch time was calculated as the difference in time between the user tapping on redBus icon on phone to the time when he would see the home screen

How we achieved it ?

1. 3rd party SDK’s were consuming a lot of time to get initialised.

The SDK’s that are critical at app launch were retained and the once that are not critical were moved to a different thread for initialisation.

2. Legacy read/writes to SharedPreferences were differed to run in parallel.

What we felt is missing from Firebase Performance Analytics?

ALERTING :

If there was a feature which can warn us through Email Or SMS on the health of certain performance metrics, it would be very useful. Just like how Crashlytics(Fabric) warns us of fluctuations or resurgence of certain crashes/issues.This would be of great value.

Eg: Considering an engineering use case

1. When certain REST API starts returning errors for a specified period, an alert in the form of Email would certainly help us to address it as soon as possible before it causes a lot of damage

2. There was an upgrade to network where TLS version of 1.0/1.1 were made obsolete due to security concerns. This made the app unusable in KitKat devices since TLS 1.2 was not enabled by default and we had to write a wrapper to support TLS1.2. We discovered this only through complaints from customers. In this case, the data is available with Firebase Performance Monitoring System. The API’s are failing and only for KitKat. An alert would have been of critical value to the engineering teams.

What more are we doing?

We would be using Screen Rendering and custom trace metric to analyse where we can improve. We believe that fine tuning rendering times would give us a boost in the rendering vitals on play store as well. Better vitals help with discovery on google playstore in turn.

Conclusion:

So far our experience with Firebase Performance monitoring has been very fruitful. Multiple dimensions of data has given us access to the client system which was previously hard to get hold of.