Mobile app performance: the numbers users actually feel
Cold start under two seconds, interaction response under 100 milliseconds, no dropped frames while scrolling. Everything else is engineering vanity.
Key takeaways
- Cold start under two seconds, tap acknowledgement under 100ms, and smooth scrolling are what users perceive.
- Defer SDK initialisation and configuration fetches off the first-screen critical path.
- Test on mid-range devices, throttled networks, cold starts and realistic data volumes.
- Read field data at the tenth percentile; the average hides the users who are about to uninstall.
Users perceive three things: how long the app takes to become usable, whether it responds immediately when touched, and whether scrolling is smooth. Practical targets are a cold start under two seconds on a mid-range device, visible response to any tap within about 100 milliseconds, and no dropped frames during scrolling. Everything else matters only insofar as it affects those three.
- < 2s
- cold start to usable on a mid-range device
- < 100ms
- visible response to a tap, the threshold for feeling instant
- 60fps
- sustained scrolling with no dropped frames
Cold start is where you lose people
The first launch after install is the highest-stakes moment the app will ever have, and it is usually the slowest because caches are empty and the network is doing everything at once. The common causes of a slow start are initialising every SDK synchronously before the first screen, fetching configuration on the critical path, and rendering a splash screen that waits for data rather than showing structure immediately.
The fix is sequencing. Show something real as fast as possible, defer everything not needed for the first screen, and load analytics, crash reporting and advertising libraries after the interface is interactive rather than before.
Responsiveness beats raw speed
An app that acknowledges a tap within 100 milliseconds and then takes a second to finish feels faster than one that does nothing for 600 milliseconds and then completes instantly. Acknowledge every interaction immediately, show progress for anything longer than about a second, and use optimistic updates where the operation is likely to succeed and cheap to reverse.
Test on the devices your users have
- A mid-range Android handset two or three years old, not the newest flagship the team carries.
- A throttled network. In parts of the region a large share of usage is on congested mobile data rather than good WiFi.
- A cold start after a reboot, not a warm relaunch from memory, which is what developers usually test by accident.
- With real data volumes. A list performs differently at ten items and at two thousand, and only one of those is what customers will have.
Measure in the field, not the lab
Instrument cold start time, screen transition times and crash-free session rate from real installations, and read them by device class and by country. An average hides everything. What you are looking for is the tenth percentile, because that is where the users who uninstall live, and improving it moves retention in a way improving the median does not.
Acknowledging a tap in 100 milliseconds feels faster than finishing the work in 600.