Skip to content

Commit 8d920ad

Browse files
committed
Refine docs based on feedback
1 parent 17d9a46 commit 8d920ad

File tree

1 file changed

+9
-6
lines changed
  • docs/product/insights/mobile/mobile-vitals

1 file changed

+9
-6
lines changed

docs/product/insights/mobile/mobile-vitals/index.mdx

Lines changed: 9 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -27,12 +27,14 @@ While the SDKs differentiate between cold and warm starts, they don't track hot
2727

2828
## Slow and Frozen Frames
2929

30-
To track the responsiveness of the user interface, Sentry measures _slow frames_ and _frozen frames_. Typically, a phone or tablet renders 60 frames per second (fps). At 60 fps, every frame has 16 or 16.67 ms to render.
30+
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.
31+
32+
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.
3133

3234
- **Slow Frames**: Using 60 fps, slow frames are frames that take more than 16 ms (Android) or 16.67 ms (iOS) to render.
3335
- **Frozen Frames**: Frozen frames are frames that take longer than 700 ms to render.
3436

35-
For Apple, the frame rate can be higher, especially as 120 fps displays are becoming more popular. For these apps, Sentry detects the frame rate and adjusts the slow frame calculation accordingly.
37+
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.
3638

3739
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.
3840

@@ -49,7 +51,7 @@ You can track slow and frozen frames for:
4951

5052
## Frames Delay
5153

52-
Frames Delay is the user-perceived delayed duration of rendered frames. For example, at a refresh rate of 60fps, if a single frame render takes 20ms, the frame delay is 4ms (20ms - 16ms = 4ms).
54+
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).
5355

5456
You can track frames delay on the following platforms:
5557
- [Android](/platforms/android/tracing/instrumentation/perf-v2/#frames-delay)
@@ -58,10 +60,11 @@ You can track frames delay on the following platforms:
5860

5961
## Time to Initial Display and Time to Full Display
6062

61-
To track how long it takes your application to produce its first frame and then how long it takes to produce its first frame with all the content, Sentry measures time to initial display and time to full display, respectively.
63+
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.
64+
65+
- **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.
6266

63-
- **Time to initial display**: tracks how long it takes for your mobile application to produce 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 automatic and enabled by default.
64-
- **Time to full display**: tracks how long it takes for your mobile application to produce 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.
67+
- **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.
6568

6669
In the example below, the detail view of the transaction displays the time-to-initial-display span in an Android application:
6770

0 commit comments

Comments
 (0)