App startup time optimization

A few years ago, I went to buy a car, and even after taking an appointment for the purchase was made to wait. I had taken the test drive, I was experiencing the famous frequency bias and I just had to make a payment but the dealership was highly mismanaged and made me wait without regular communication. I decided to buy the car from another dealership instead. Don't lose business like this dealership by making customers wait for your app to start.

Your marketing team whips up a brand new campaign and gets potential customers to download your mobile app. They open it and then 25% of them never open the app again. If the customers face performance issues more than 60% of them are likely to abandon your app. I had made up my mind about the car but changed dealerships, your customers will do that too.

The first impression of a mobile app's performance comes at the startup time. For mobile apps all three startup times (cold start, warm start, and hot start) are important. A cold start is like getting the seats in a restaurant. A warm start is getting the food and a hot start is much like getting the menu.

• A cold start can take some time, it's similar to food being served. Unless you are a fast-food restaurant, food takes time to prepare. the mobile operating system has to create space for your application and many parts have to fit in limited memory.
• The warm start can also take some time; I compare it to getting you seated. It can take some time but not a whole lot.
• The hot start should be the fastest. Getting the menu shouldn't take time. For mobile apps, it means your application is in memory but is in the background. It should snap back to life and wait for the customers' orders.

Google considers your app's startup time to be excessive when:

• Cold startup takes 5 seconds or longer.
• Warm startup takes 2 seconds or longer.
• Hot startup takes 1.5 seconds or longer.

Apple doesn't really quantify these numbers but has some really good advice for reducing app start time.

Both Google and Apple have some really good advice that I recommend all mobile developers to go through them. In my experience, the problems highlighted in these documents are often not the problems that affect many applications. Here are some common problems and potential solutions I have seen:

Measure it

"What Gets Measured Gets Improve", legendary management expert Peter Drucker said many years ago. Many teams just fail to measure app startup time. In many cases even if it's being measured (thanks to default instrumentation by the likes of Firebase), nobody is looking at the metric.

Start here! Start measuring and monitoring app startup time. Android Play Console can give you the data and alerts for Android apps. With MetricKit it will become easier for iOS applications to get this data easily. I have often relied on Firebase performance API to give me this data. Firebase works for React Native applications too and that's what my team uses. When React Native Hermes came in, we ported our apps and immediately saw 30+% improvement in startup times.

Use Splash Screen Cleverly

When lifts (or elevators as they are called in some parts of the world) first started being used, people found them slow and they complained. The lift designers added mirrors in the elevator. This distracted the people when they were in the lift and complaints stopped even before we got express speed elevators.

Put your app start splash screen and the animation time to good use and fetch data from your APIs in parallel. Your customers are watching that animation anyway, don't let that time get wasted and bootstrap your application's configuration, etc. in parallel.

Don't let the APIs block you

I recently started cooking and the new cook in me still makes only one dish at a time and if possible I would like to not chop onions while I am also monitoring the milk from boiling. Don't be like me. Professional cooks can do multiple things at the same time, at least the timeslice and context switch very quickly.

Look at API flow properly. Then look at it again. Which APIs need to be blocking APIs? Which ones can be executed simultaneously? Put the computers to use and fire your APIs away. Do your third-party SDKs provide async initialization? Consider using that flow.

While first-time app start may pose a problem, second-time starts (including cold and warm) can use local storage to their advantage and avoid some API calls altogether.

Being lazy is good

This is not the same lazy Bill Gates referred to when he said, "I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it." I would ask for smart people who are not satisfied with the status quo over lazy people. But for app startup time optimization, I like lazy.

Database initialization - Go for lazy initialization. Huge static objects/configurations - Go for lazy and one-time initialization (hot starts become super fast), huge dependency tree to be loaded for an Android app - Be lazy and see the performance benefits.

Images are cute until they are not

When I go for a 2-3 days outing from Bangalore, I manage to carry a lot of snacks with me (just in case). Most of it comes back unopened but it does increase the weight I have to carry. Images are like snacks, we love them and manage to pack large quantities.

We love our brand and the great product images on our app. Unfortunately, rendering images is CPU intensive and could often be a reason for performance bottleneck. Look at the number of images you load (are you loading from the network?) and see if you can reduce the images and make it easy for mobile phones to render them (raster images are better than vector images for rendering performance).

IMHO, app startup time optimization is an exciting and decently advanced topic. Right from network IO and multi-threaded processing to using local storage and dynamically loaded libraries; all topics are important.

Spend time optimizing your app's startup time and you should automatically see other business metrics improve.