Is Your App Slow? Before Optimizing, Find Out Why

As users, we have all experienced the dreadful experience of using an application that reacts to taps with a slight delay, with screens that take whole seconds to load or that even stays stuck on the screen preceding the main interface.

It is not a secondary problem. A slow application:

• Generates frustration in the user
• Leads the user to abandon it
• In the long run, lowers ratings on the stores
• Results in lost revenue

But how do you step in when an application doesn't behave as expected? Optimizing blindly is not the solution. The first step is to understand exactly where the problem lies and to intervene in a targeted way.

The causes of a slow application

Saying that the app is slow is like going to the doctor and saying "I feel sick": it's a useful indication, but too imprecise to find a solution. For obvious reasons, however, it is also the kind of report users make most often.

In the urgency of keeping users from fleeing, your first instinct might be to dive straight into optimizing the app. Don't: proceeding without guidance would only be a waste of time and money.

The first step is to understand what "the app is slow" means: users themselves sometimes provide, in their reviews, indications that shouldn't be overlooked.

How to assess what kind of slowness

In our experience, there are at least five types of slowness that can be identified. Each of them has specific characteristics and points to a different area that requires optimization.

To understand what speed to expect from an application, keep in mind that at 60Hz a frame redrawn every 16 milliseconds is considered smooth. For Android, a frame over 700 milliseconds is considered a frozen frame; for the user, on the other hand, the app is simply stuck.

How to tell the cause of slowness apart: tools and procedures

Being able to identify the underlying reason is not a matter of intuition, but of method. The method we use at Mabiloft requires four precautions:

Reproduce the problem. If the problem can't be replicated, it isn't possible to intervene in a targeted way. Seeing the problem with your own eyes lets you answer questions such as: on which screens does it happen, when does it happen, and does it do so consistently or only sometimes?

Measure under the right conditions. The more similar the conditions are to the user's, the more reliable the measurement. This is why it's good to use a real device rather than a simulator, and a build as close as possible to the one actually used by users.

Segment the problem. Narrowing the field brings us closer to the cause of the problem. This means identifying whether the problem occurs only on low-end devices or on all of them, only on Android or iOS or on both operating systems, from which version the app started to slow down, and so on.

Separate client and server. If the API response is fast but the screen loads slowly, the problem is in the application. If instead it's the server making the app wait, then the backend needs to be checked.

It might seem like a lot to keep an eye on, but free monitoring tools for each platform come to our aid: we use Flutter DevTools, but there are several for iOS, for Android, and also cross-platform.

Improving the application's speed

Once the problem has been identified, it's possible to establish the methods with which to intervene. Obviously, the solution strictly depends on the cause identified.

Finally, to correctly identify the cause of the problem, each fix must be applied individually: this means measuring a "before" and an "after", so as to have a definite measure telling us whether our intervention solved the problem.

Fixing a slow startup

As we said, a slow application startup depends on initializations in the wrong place. It's a problem we encounter often, and a rather insidious one: the application works, it does what it has to, but the user complains that it takes forever to open.

What happens under the hood is that at startup, before the first screen is shown, everything immediately starts running: analytics, crash reporting, push notifications, remote configurations, local database, advertising SDKs, and you name it.

Each element individually adds just a few hundred milliseconds, but overall the splash screen stays on screen for several seconds.

This problem is often made worse by immediately requesting all permissions: camera, notifications, location, even before the user has seen the application working, with the result of coming across as somewhat suspicious and intrusive.

The fix for this problem is usually simple:

• Distinguish what is essential for the app to start and limit yourself to that. Everything else can be moved to the background while the user is using the app.
• For whatever doesn't depend on anything else, it can be useful to parallelize, rather than running all processes in sequence.
• Any permission requests can happen when needed: when trying to access a "Map" section, for example, consent to detect location can be requested, rather than asking for it in advance.

Other problems to know and fix

Of course, slow startup is only one of the possible problems. An accurate analysis makes it possible to identify and fix most of the problems.

For example, if the interface stutters, the problem is often related to widgets that redraw more often than necessary, or to lists that build all their items, even those not in view, or to heavy graphic effects. In Flutter, in particular, poorly thought-out state management can lead to rebuilding entire screens when a single piece of data changes.

If instead it's the main thread that is blocked, there may be very large JSON files involved, or images may be being processed on the same thread that draws the interface. The solution, of course, is to move these tasks to the background.

Other common problems include memory leaks, especially if the problem occurs on older devices with little RAM, and local database problems, such as queries without indexes and synchronous reads and writes performed during navigation.

When the app is the one waiting

The user waits for the app, but sometimes the app is waiting for the server. Some typical causes are:

• Responses that are too heavy, with the API returning huge objects even if only a few fields are needed on the screen.
• If displaying a screen requires five different requests, you run the risk of making too many cascading calls, each waiting for the previous one.
• No cache: the same data has to be downloaded again every time.
• Slow or overloaded server, with poorly optimized queries.

Even for a mobile developer it can be useful to know these aspects, so as to foster dialogue between teams. This also means thinking about the endpoints together, in relation to the screens that need to be built.

On the app side, it's also possible to immediately show cached data and update it at a later time, to spare the user that tedious wait in front of a spinner.

How to build a fast app

An app is rarely slow because of a single mistake, although of course it can happen, in the case of glaring errors. But more often, mistakes pile up: a useless SDK, one call too many, screens that grow bigger with every release.

Therefore, it's good to try to prevent the problem, treating app performance as a team habit rather than an emergency to deal with when negative reviews start pouring in.

Good habits that prevent slowness

Some good habits can help resolve unpleasant situations before they occur.

For example, it's good to test the app on different devices: a latest-generation phone doesn't perform like a phone that is 3 or 5 years old. But the average user doesn't always use up-to-date, top-of-the-range devices.

A policy for evaluating SDKs should also be introduced: every library has a cost when it starts up and takes up memory. Whatever is superfluous and may affect loading times should be left out by default, rather than throwing everything in and then possibly cleaning up afterwards.

In addition, monitoring should be added for every version: historical data makes it possible to identify any problems more quickly and, if necessary, roll back to previous versions. Moreover, it lets you immediately discover a decline in performance.

To make our work easier, we can also add a startup time check directly to the release checklist, along with the tests: it takes a few minutes, but it catches regressions before users notice them.

Designing for speed

A slow app is not a life sentence and almost never requires starting from scratch. The difficulty, however, is not fixing the cause, or more often the causes, but finding them. That's why setting up a well-structured system from the start makes it possible to avoid the most common problems, but also to fix them more quickly.

If your application is slow and you don't know where to start to improve its performance, you can contact us. We'll help you identify the weak spots, fix them one at a time, and get ready for your next release.