Performance is the growth lever founders least expect to be a growth lever. It feels like an engineering concern, something to optimize later, once there are enough users to justify caring.
The numbers say otherwise, and they are harsh. Apps that take longer than three seconds to load can lose the large majority of first-time users. Around 62% of users uninstall an app after experiencing a crash, freeze, or error, with freezing cited by roughly three quarters of frustrated users. And since something like 46% of users uninstall within thirty days anyway, you do not have margin to spend on a slow first impression.
Here is what matters, in the order it matters, for a small app.
Speed is an onboarding problem wearing a technical costume
Think about where launch time actually lands. Someone installs your app, taps it for the first time, and waits. They have no investment yet, no habit, no reason to be patient. This is precisely the moment your onboarding is trying to get them to a value moment fast.
A four-second cold start eats a meaningful chunk of the attention you were counting on. Worse, slowness reads as unreliability: users infer that an app which takes a while to open is probably also going to lose their data or drain their battery. That inference is usually wrong and always expensive.
The benchmarks to aim at:
- Under 2 seconds for cold start is where good apps sit
- Under 3 seconds is the threshold beyond which drop-off climbs sharply
- Beyond 4 seconds users describe the app as slow, and many never reach your core screen
The same logic applies inside the app. Every screen that takes a beat too long is a small tax on the habit you are trying to build.
Test on the phone your users actually have
This is the single most common blind spot, and it is worth stating plainly: your app is fast on your phone because your phone is new and your network is good.
A large share of the global installed base runs mid-range Android devices that are several years old, on connections that are not your home wifi. Crashes, slow starts, and stuttering interfaces spike disproportionately on exactly those devices. If you only ever test on a recent flagship, you are measuring an experience most of your users will never have.
Practical version: get hold of a cheap Android device a few years old, keep it, and open your app on it before every release. Also test with the network throttled, which most development tools can simulate, and test on a device with limited free storage, because low-storage phones behave differently.
This one habit catches more real-world performance problems than any profiling tool.
The four things worth fixing first
For a small consumer app, performance debt clusters in predictable places.
1. Work happening at startup that does not need to. The most common cause of slow cold starts is initializing everything the app might eventually need before showing anything. Analytics, crash reporting, remote config, feature flags, ad SDKs: each adds startup time, and third-party SDKs are frequent offenders. Defer everything that is not required to render the first screen.
2. Images. Oversized images are the most common performance problem in consumer apps and the easiest to fix. Serve appropriately sized assets rather than full-resolution originals scaled down at display time, compress aggressively, and load lazily below the fold.
3. Blocking the interface on network calls. If the first screen cannot draw until an API responds, your app is as slow as your slowest user's connection. Show the shell immediately, fill it as data arrives, and cache the previous state so returning users see something instantly.
4. Crashes on specific devices. A crash rate that looks fine in aggregate can be concentrated on one OS version or device family, where it is catastrophic. This is why crash reporting matters even at small scale: you need the breakdown, not the average.
What to actually measure
Four numbers, all available from standard tooling:
- Cold start time, the launch-to-usable duration from a fully closed state. Measure it on the old device, not the new one.
- Crash-free session rate. Both stores surface this, and both use it as an input to how they treat your app. Anything below roughly 99% deserves attention; below 98% is an emergency.
- Time to your core value action, which combines technical speed with design. This is the number that actually predicts retention.
- Performance by device and OS, because that is where problems hide. An average conceals the segment that is having a terrible time.
Both platforms provide performance and stability reporting in their developer consoles for free. Read it monthly. It tells you things your users will never bother to.
Why stores care too
Beyond users, the platforms themselves weigh technical quality. Stability and performance metrics feed into how apps are surfaced and treated, and persistent quality problems can affect visibility. So performance is not only a retention lever, it is quietly an acquisition one.
There is also the review channel. Performance complaints are among the most common one-star reviews, they are specific and memorable, and they are read by everyone considering your app. Given that a rating below 4.0 can cost most of your store conversion, a crash-driven review spiral is expensive well beyond the users who experienced it.
A realistic maintenance rhythm
You do not need a performance culture. You need a few habits that prevent the slow accumulation of debt:
Before every release: open the app on the old test device, cold, and watch the clock. If it got slower, find out why before shipping.
Monthly: read the crash-free rate and the performance report in both consoles. Look at the breakdown by device and OS, not the headline.
When adding any SDK: measure cold start before and after. Third-party libraries are where startup time goes to hide, and the cost is invisible unless you check.
When a crash cluster appears: treat it as urgent. A crash affecting 3% of sessions is quietly destroying your retention and your rating simultaneously, and it will not announce itself.
The founder version of this
If you are non-technical and reading this wondering what you are supposed to do with it, the answer is mostly: notice, measure, and insist.
Open your app on a cheap old phone. Time it. If it takes more than three seconds, that is a problem worth prioritizing over your next feature, because it is silently capping everything else you build. Check your crash-free rate monthly and treat a dip as a real issue rather than a technical detail.
Performance work is unglamorous, and it never produces a screenshot you can post. But it is one of the few areas where the fix is well understood, the measurement is free, and the cost of ignoring it is paid quietly by every user who taps your icon, waits, and decides they will come back later.
They rarely do.
Originally published at https://foundyra.com/news/app-speed-and-retention
Top comments (0)