Organizations worldwide are racing to build applications that reach their customers where they are—and often that means mobile phones and tablets. Slow and bug-ridden mobile apps leave users frustrated or even drive them to competitors.
Creating exceptional user experiences across a plethora of mobile devices and platforms is imperative, but seeing and solving performance issues can be a struggle and time-consuming. While testing an application before it ships is important, many times test environments do not replicate real conditions, and performance regressions may not show.
To catch the most frustrating performance issues, mobile development teams need to explore what’s happening on users’ devices. This requires visibility into how fast the app starts, duration of HTTP requests, number of slow and frozen frames, how fast views are loading, and more.
Although there are a number of metrics to consider, below are the five most important that every mobile team should track to better understand how an app is performing.
1. Crash-Free Users and Sessions
A crash is considered to be an unhandled error. This could happen during the initial load phase of an application or at any time during an application’s use. Tracking the percentage of users that did not experience a crash, as well as the number of sessions that did not end by the crash of the application, are important KPIs for measuring application stability.
Tracking and comparing these numbers from release to release can also surface trends and provide valuable insights about code health.
2. Cold and Warm App Start Times
When a user taps on an app icon, it should start fast. App start time values represent the amount of time elapsed between launching the process and finishing drawing the corresponding activity on the screen.
Apple recommends that iOS apps take—at most—400 ms to render the first frame. The Google Play Console warns Android developers when an app’s startup times are excessive. This includes when a cold start (defined as when an app is launched for the first time or after a reboot or update) takes longer than 5 seconds or a warm start (an app launched at least once and is partially in memory) takes longer than 2 seconds.
No matter the platform, it is crucial that an app starts quickly, as this is a user’s first touch with a company, and slow load times leave a bad first impression. On iOS, Mac Catalyst, tvOS, and Android, companies should track how long their app needs to draw the first frame. This information can help improve the duration of the app start.
3. Slow and Frozen Frames
Unresponsive user interface, animation hitches, and other app jank annoy users and degrade the user experience. Two mobile vitals that measure these issues are slow and frozen frames.
A phone or tablet typically renders with 60 frames per second (fps), though the frame rate can be as high as 120 fps. With 60 fps, if an app takes longer than 16.67 ms for a frame to render, it is considered a slow frame. Frozen frames are UI frames that take longer than 700 ms. An app that is running smoothly should not experience either.
4. User Misery
User Misery is a user-weighted performance metric to assess the relative magnitude of application performance. While developers can examine the ratio of various response time threshold levels, User Misery counts the number of unique users who were frustrated based on four times the satisfactory response time threshold (ms). User Misery highlights transactions that have the highest impact on users.
Resolving Mobile Performance Issues
These mobile vitals can unlock valuable insights into user experience and enable developers to better understand how code changes impact their applications. Decreases in crash-free sessions or users, slow cold and warm starts, and slow or frozen frames are all key indicators that performance is diminishing, and quick action should be taken to determine where the issues lie.
An effective way to resolve mobile performance issues is distributed tracing, defined as a method of recording the connected operations of multiple services. Typically, these operations are initiated by requests from one service to another, where a “request” could be an actual HTTP request, or work invoked through a task queue or some other asynchronous means.
Although this is a standard technology used for understanding what’s going on across distributed services, it is still relatively new for mobile applications. Ultimately, teams looking to manage and optimize mobile performance will find great success when monitoring the right vitals and adopting distributed tracing techniques to more efficiently debug mobile applications.
About the Author:
Philipp Hofmann, software engineer, Sentry