How we improved the mobile app startup time at car2go
TLDR;
We analyzed all remote information we need, cached more or less static information, added a modern and fast authentication process and utilized the speed of MQTT connection for getting fast-changing, highly important data.
Just recently I read a tweet which made me feel very good on the one hand and which started a new thought in myself on the other hand.
Of course, it’s always super nice to hear that from one of our customers — even better from a user of our app. In addition, I asked myself why didn’t we share what we did and documented it may be in a blog article. So even though it’s already long ago that we did the improvements I am proud to share what we did.
Before implementing some potential improvements we did a deep analysis of our apps. What is really happening at startup?
In particular, which REST requests are being made and are there any cross dependencies? Do we need some specific resources to be present before we can offer a customer to reserve or book a vehicle?
How much time do these requests take and how big is the actual payload?
We tested everything with a simulated limited bandwidth to see really what happened in worst case edge mobile data connection.
What we also did is documenting average startup speed for a specific scenario.
App opening -> waiting until all vehicles are displayed -> reserve the closest vehicle.
How should we else compare our improved version to the current state?
So here is what we found and how we improved it:
First of all, we realized that we need some specific set of data to be downloaded before we can proceed with downloading the actual vehicle data.
This is really static data about our locations and it’s not really likely to have too many changes over time. We decided to cache this data to have it already present. The download is still being made, but the result will just update the local cache.
Also our authentication progress took lots of time (and lots of different REST requests). Luckily, we already decided as a company to replace this authentication service in the backend. Now just one request is needed to obtain an authentication token with which the user can successfully authenticate to reserve vehicle.
We also thought it would have a big impact when we add a prioritization information to each REST request and let the network layer do all requests dependent on that info. The idea was that important requests which are absolutely needed to proceed to a reservation or rental of a vehicle should be done exclusively first. In the end we realized that it did not have a huge impact.
Together with our backend teams, we added e-tag and caching headers to the resources our mobile application uses.
In short: If the data did not change the backend does not send it again. Instead, it tells the network layer of the client that nothing changed and therefore it will reuse the last known data.
Important to say is also that we do not use REST for downloading the vehicle information.
The mobile clients consume this data through a message queue (MQTT). In addition we work with delta updates to reduce the amount of data which needs to be sent very frequently.
Nevertheless we limited the power of that fast vehicle update with the prepended REST requests in the past. With techniques of client-side caching plus a more modern and quick authentication, we can utilize the speed of MQTT as fast as possible. 💪
On average we were able to reduce the app startup time to 27%. Also, we saved our users up to 52% of mobile data with this small, but necessary improvements.
Why 27% and not as in the initial tweet mentioned 15 seconds to < 1 second hop?
Well, our test scenario was more or less static to gain a better comparison. I can imagine that real-world comparisons also have to deal with comparing edge to LTE “sessions”.
Additionally, this comparison probably takes into consideration that we switched our vehicles update from pulling REST to subscribing to an MQTT topic.
