Mobile Vitals
Track the performance of your app.
The Mobile Vitals insights module provides a high-level overview of the performance of your screens, and allows you to drill down into the performance metrics of individual screens.
App start metrics track how long your mobile application takes to launch. For this, Sentry measures cold starts and warm starts.
The definitions of cold start and warm start change slightly depending on the operating system. On iOS, Apple recommends your app take at most 400ms to render the first frame. On Android, the Google Play console warns you when a cold start takes longer than five seconds or a warm start longer than two seconds. For definitions by operating system, check out the corresponding SDK docs:
In the example below, the detail view of a transaction displays the warm start measurement in the right sidebar.
While the SDKs differentiate between cold and warm starts, they don't track hot starts or resumes. To get more insight into your cold and warm start metrics, you can use the App Starts feature.
To track the responsiveness of the user interface, Sentry measures slow frames and frozen frames. Both indicate if the rendering of a frame is taking too long, causing the UI to appear laggy or frozen.
Typically, a phone or tablet renders at 60 or 120 frames per second (fps). Based on this a single frame has a time budget of 16.67 / 8.33 ms to render.
- Slow Frames: Using 60 fps, slow frames are frames that take more than 16 ms (Android) or 16.67 ms (iOS) to render.
- Frozen Frames: Frozen frames are frames that take longer than 700 ms to render.
Sentry also supports higher frame rates, especially as 120 fps displays are becoming more popular. For these apps, Sentry detects the frame rate and adjusts the slow frame calculation accordingly.
On the Mobile Vitals insights page, you can see a slow and frozen frame rate, indicating the percentage of frames that are slow or frozen during the lifetime of the transaction.
In the example below, the detail view of the transaction displays the slow, frozen, and total frames in an iOS application:
You can track slow and frozen frames for:
Frames Delay is the user-perceived total delayed duration of rendered frames. For example, at a refresh rate of 60fps, if a two frame renders takes 20ms each, the frame delay is 8ms (2 * (20ms - 16ms) = 8ms).
You can track frames delay on the following platforms:
To track how long it takes a screen to render its first frame and then how long it takes to render its first frame with all content, Sentry measures time to initial display and time to full display, respectively.
Time to initial display: tracks how long it takes your app to render its first frame. This includes app start time on the first screen loaded. It doesn't include any content loaded lazily after the first frame is drawn. Time to initial display is measured automatically and enabled by default.
Time to full display: tracks how long it takes for your mobile application to render its first frame with full content. This includes content loaded asynchronously after the first frame, for example, after loading content from the network. Time to full display is opt-in and requires you to manually call the API to report that the screen has loaded all of its content and is fully displayed.
In the example below, the detail view of the transaction displays the time-to-initial-display span in an Android application:
You can track time to initial display for:
You can track time to full display for:
To get more insight into the performance of your time to initial display and time to full display metrics, use the Screen Loads feature.
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) or suggesting an update ("yeah, this would be better").