Top 5 factors slowing down app startup

As an engineer, you know that the success of your mobile app depends on both its speed and responsiveness. You also know that your app’s startup time is one of the most important first impressions you can make on a user. When users open your app, they’re expecting it to launch quickly and seamlessly — anything less leads to user dissatisfaction and abandonment. If you’re aiming for increased visibility, downloads, and satisfied customers, then it’s important to understand the five most critical factors that may slow you down.

In this blog post, we’ll discuss the following:

• What is app startup?
• The types of app startup
• Factor 1: Excessive initialization
• Factor 2: Large images and media files
• Factor 3: Excessive disk read operations
• Factor 4: Network requests
• Factor 5: Trampoline startup activity

If you only take one thing away from this blog post it should be this: Do not do work during app startup, unless it’s absolutely necessary. 

By minimizing the work your app needs to do during startup, you can significantly improve its launch speed and provide a better user experience — this is a key app performance optimization technique. 

With that in mind, let’s begin with some housekeeping.

What is app startup?

App startup is the process of loading an app and preparing it for use by a user. This involves initializing the app’s code, loading necessary resources such as data and media files, and setting up the app’s user interface. While the app can be started up in a number of ways, typically, the specific startup workflow we care about the most is when the app startup is triggered directly by a user opening the app.

Engineers should consider multiple factors when measuring and optimizing app startup, to avoid falling victim to using “industry standards” as their only measuring stick. That’s because it can be difficult to standardize on a single measurement of app startup or use just a single number to determine if your app is performing well due to the variability of app complexity and user behavior. Different apps with different use cases and user bases, for example, will have different startup time requirements and performance expectations. 

The types of app startup

Broadly speaking, app startup can be separated into three categories: cold, warm, and hot. 

Cold starts refer to when the operating system has to start from scratch to create the app process, load system and app-specific code into memory, and initialize the app itself before displaying the first screen to the user. 

Warm starts refer to a scenario where the app process has already been created (due to a background job or notification), but the app itself isn’t fully initialized. 

Meanwhile, hot starts are when the app has been fully initialized already but has since been backgrounded, and the startup merely brings the app back to the foreground at the user’s request.

While native platforms offer some visibility into app startup times, they may not provide enough nuance for you to narrow down bottlenecks or pinpoint where to look for optimizations in the code.

Top 5 factors contributing to slow app startup

Using startup metrics effectively can be difficult because current monitoring solutions don’t make it easy to spot areas for improvements. Engineers typically rely on traces or custom timing data to determine problem areas when optimizing app startup to provide a better user experience. 

Additionally, there are a few common factors that contribute to slow app startups that engineers can actively seek to eliminate if they want to improve their app’s performance. Here, we’ll review the top five factors that slow down your app startup time, and what you can do about them.

Factor 1: Excessive initialization

Excessive initialization is one of the factors that can slow down app startup. Excessive initialization occurs when an app performs more initialization than necessary, leading to longer startup times.

For example, an app might load multiple libraries or components that are not needed during, or right after, startup. This unnecessarily increases the time it takes for the app to become responsive. Additionally, some apps may perform excessive computations during startup that could be deferred until later in the app’s lifecycle. It’s like buying something now that you don’t need right away when you are short on cash.

To reduce initialization time, engineers can use techniques such as lazy loading. Lazy loading involves deferring the loading of components until they are needed, reducing the amount of initialization that occurs during startup.

This is like buying something right when you need to use it. 

You can also load components on background threads to reduce the burden and blocking of your main thread. It is particularly useful when a device CPU has many cores which allows it to run many different threads in parallel without creating resource contention that slows down the startup process. 

This is like when you ask other people to buy things for you and never have to pay them back — it’s great when it works! 

Factor 2: Large images and media files

Large image and media files are another factor that can slow down app startup. When an app loads large images or media files in inefficient formats during startup, it can significantly increase the amount of time it takes for the app to become responsive because of the time it requires to both load and decode these files.

To reduce the impact of large images and media files on app startup time, consider using more efficient image formats like SVG or JPEG (as opposed to big PNGs). Further, consider changing the user interface to use fewer images initially — the fastest image to load is not loading an image at all.

Factor 3: Excessive disk read operations

Disk read operations such as database queries can bring your app’s startup to a crawl if they’re excessive. This is because an app performing a large number of complex database operations during startup significantly increases the amount of time it takes for the app to begin performing due to disk access being slow; a good reminder that it’s vital to stick to only what is necessary during startup.

Consider reading only the subset of data that the app needs to show right at startup. If complex database operations are what’s slowing the app down, consider restructuring how the data is stored or read. Additionally, you can even do some pre-computation to optimize the read-path. Newer and faster frameworks can also be leveraged to reduce the time it takes to load data from disk.

And, like initialization, if you can defer data load until after your app finishes starting up without hampering the user experience, consider that as an option as well.

Factor 4: Network requests

Network requests can be a deterrent to fast app startup. Network requests that block startup are an obvious problem — but even the practice of sending numerous network requests upon startup that don’t block the activity pose a threat to your app. This is because spinning up the network library and processing multiple requests takes up valuable resources at startup, even if it’s done on background threads.

The unpredictable nature of networks means that slowness and failures are to be expected, so you can’t depend on them in your startup workflow even if you are only requesting a small amount of data.

If you’re aiming to reduce the amount of network requests happening during your startup, you can delay issuing them until the app startup is completed. It may sometimes be easier to request new data when a component is first initialized, but you should be more deliberate about when that’s done as it may have a downstream effect on app startup.

Factor 5: Trampoline startup

Trampoline startup is a term describing an anti-pattern when the first UI view (e.g. Activity on Android) created by an app is not the UI view that the user first interacts with.

During trampoline startup, an app opens with a hidden screen or splash screen and then immediately redirects to another UI view. It is typically used to show an app loading image, do some processing, or simply used for redirection based on some runtime factors to the real UI view to be opened.

Trampoline startup is not ideal because it unnecessarily delays the initialization of the UI view during startup. When this is done, the time to load and transition from the UI view that was trampolined from to the main UI view is added to your app’s startup time.

To avoid this, always launch into the UI view that you want to load after app startup, and put any preprocessing logic into the code of that UI view.

If you need a splash screen, consider using the SplashScreen API for Android and referencing this launch documentation for iOS. If the app is effectively blocked from being interactive until something slow finishes (like requesting data from the server) don’t put this into a separate UI view. Instead, do the loading and show the indicator in the same place users are expecting to see.

Final thoughts

Your app’s startup is your opportunity to make a great first impression on your users.

When you address factors such as excessive initialization, large images and media files, excessive disk read operations, network requests, and trampoline startup activity, you provide a better overall user experience — and a better first impression.

While these tips can help you avoid common factors that contribute to slow app startups, fully optimizing your app will require appropriate tooling. With Embrace, you have the tooling necessary to remain proactive. Our platform helps you spot performance issues and uncover their root causes quickly through use of intuitive, out of the box metrics.

Want to get to the bottom of your app startup speed issues? Explore Embrace today.