Full Article
The 5 numbers that decide whether users keep or delete your app
Nobody thinks about "performance metrics." They just notice when something feels slow, or crashes, or won't open. Then they leave.
Nagarajan Madhavan at BITS Pilani published a peer-reviewed paper that compiled industry research into specific thresholds for five metrics. The numbers are more punishing than most teams realize.
1. Crash rate
The benchmark is under 0.1% of user sessions. Apps above 1% lose 26% of their users within 30 days. 65% of users lose trust after just 2 crashes. After 3, nearly a third abandon the app entirely.
Most users consider anything above 0.2% unacceptable, so the gap between "fine" and "uninstalled" is narrow. One bad release can close it.
2. App start time
Under 2 seconds. Every 100ms you add drops conversions by 1.8%, which compounds fast. Go above 5 seconds and bounce rates jump 30%.
Cold start is what matters. If yours is north of 3 seconds, that's where the work should go: lazy initialization, deferred module loading, trimming the dependency graph that has to resolve before the first frame draws.
3. Page load time
Under 1 second, ideally under 500ms. Google found that 53% of mobile site visits get abandoned past 3 seconds. The psychology is the same inside native apps.
Each additional second costs you across the board:
| Delay | Impact |
|---|---|
| +1 second | 4% less revenue |
| +1 second | 11% fewer page views |
| +1 second | 7% fewer conversions |
| +1 second | 16% lower satisfaction |
What actually helps: prefetching content before the user taps, aggressive client-side caching, and keeping API payloads small. Skeleton screens buy perception time but are not a substitute for being fast.
4. Scroll performance
60 frames per second. That's the bar.
Drop below 30 fps and abandonment jumps 50%. A 1% improvement in scroll smoothness maps to roughly 2% more revenue and 3% more engagement. If your app is content-heavy, scroll performance is a business metric whether you track it that way or not.
5. App size
Under 200 MB is the benchmark, but 70% of users prefer apps under 50 MB. Half hesitate to download anything above 100 MB. Every 10 MB you add costs about 1% in downloads and adds 2% to uninstalls.
A user looking at "412 MB" in the App Store pauses in a way that "38 MB" doesn't cause. App size is a silent filter on your addressable market, especially in emerging markets where storage is tight and data is metered.
Offense and defense
Knowing the benchmarks is easy. Staying within them is where teams struggle, because performance degrades by default. Every feature and dependency adds weight.
The paper splits the work into two strategies, and you need both. Offense means finding and fixing the worst problems directly: top crash paths, cold start bottlenecks, slow screens, janky list views. Defense means building infrastructure that catches regressions before users do: performance budgets in CI, production monitoring, automated alerts when metrics cross thresholds.
Start with defense. Get monitoring in place so you can see where you stand. Then go on offense. Set realistic goals first (0.5% crash rate before you aim for 0.1%). Sustainable improvement over two quarters beats an aggressive target the team burns out chasing.
So what?
| Metric | Target |
|---|---|
| Crash rate | < 0.1% of sessions |
| App start time | < 2 seconds |
| Page load time | < 1 second (500ms ideal) |
| Scroll performance | 60 fps |
| App size | < 200 MB (< 50 MB preferred) |
Most teams know their crash rate. Fewer track start time carefully. Almost nobody has scroll performance budgets. That gap, between what gets measured and what actually matters, is where most performance problems live.
---
*Based on "Improving Mobile App Performance: A Comprehensive Approach" by Nagarajan Madhavan (BITS Pilani), published in SSRG International Journal of Mobile Computing and Application, Vol. 11, Issue 2, 2024. DOI: 10.14445/23939141/IJMCA-V11I2P1I01*
