chore(insights): Update docs for upcoming mobile screens GA

Author: markushi

docs/product/insights/img/mobile-performance-overview.png

@@ -10,66 +10,6 @@ The [**Mobile Performance**](https://sentry.io/orgredirect/organizations/:orgslu
 
 ![Mobile performance overview page.](../img/mobile-performance-overview.png)
 
-## App Start
+## Learn More
 
-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](https://developer.android.com/topic/performance/vitals/launch-time#av) 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:
-
-- [Android](/platforms/android/tracing/instrumentation/automatic-instrumentation/#app-start-instrumentation)
-- [Flutter](/platforms/flutter/tracing/instrumentation/automatic-instrumentation/#app-start-instrumentation)
-- [iOS](/platforms/apple/guides/ios/tracing/instrumentation/automatic-instrumentation/#app-start-tracking)
-- [React Native](/platforms/react-native/tracing/instrumentation/automatic-instrumentation/#app-start-instrumentation)
-
-In the example below, the detail view of a transaction displays the warm start measurement in the right sidebar.
-
-![The event detail of a transaction with a warm start measurement.](./img/app-start-transaction.png)
-
-While the SDKs differentiate between a cold and a warm start, 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](/product/insights/mobile-vitals/app-starts/) feature.
-
-## Slow and Frozen Frames
-
-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.
-
-- **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.
-
-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.
-
-In the example below, the detail view of the transaction displays the slow, frozen, and total frames in an iOS application:
-
-![The event detail of a transaction with slow and frozen frames measurements.](./img/slow-frozen-frames.png)
-
-You can track slow and frozen frames for:
-
-- [Android](/platforms/android/tracing/instrumentation/automatic-instrumentation/#slow-and-frozen-frames)
-- [Flutter](/platforms/flutter/tracing/instrumentation/automatic-instrumentation/#slow-and-frozen-frames)
-- [iOS](/platforms/apple/guides/ios/tracing/instrumentation/automatic-instrumentation/#slow-and-frozen-frames)
-- [React Native](/platforms/react-native/tracing/instrumentation/automatic-instrumentation/#slow-and-frozen-frames)
-
-## Time to Initial Display and Time to Full Display
-
-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.
-
-- **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.
-- **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.
-
-In the example below, the detail view of the transaction displays the time-to-initial-display span in an Android application:
-
-![The event detail of a transaction with time to initial display and time to full display spans.](./img/time-to-initial-full-display.png)
-
-You can track time to initial display for:
-
-- [Android](/platforms/android/tracing/instrumentation/automatic-instrumentation/#time-to-initial-display)
-- [Apple](/platforms/apple/tracing/instrumentation/automatic-instrumentation/#time-to-initial-display)
-- [Flutter](/platforms/flutter/integrations/routing-instrumentation/#time-to-initial-display)
-- [React Native](/platforms/react-native/performance/instrumentation/time-to-display/#automatic-time-to-initial-display-for-react-navigation)
-
-You can track time to full display for:
-
-- [Android](/platforms/android/tracing/instrumentation/automatic-instrumentation/#time-to-full-display)
-- [Apple](/platforms/apple/tracing/instrumentation/automatic-instrumentation/#time-to-full-display)
-- [Flutter](/platforms/flutter/integrations/routing-instrumentation/#time-to-full-display)
-- [React Native](/platforms/react-native/performance/instrumentation/time-to-display/#time-to-full-display)
-
-To get more insight into the performance of your time to initial display and time to full display metrics, use the [Screen Loads](/product/insights/mobile-vitals/screen-loads/) feature.
+<PageGrid />

docs/product/insights/mobile/img/app-starts-screen-summary.png

@@ -15,7 +15,7 @@ The **App Starts** page shows an overview of the amount of time it takes for you
 **For Android:**
 
 - `>=7.4.0` for automatic instrumentation of app start spans and app start profiling
-- [Performance-V2](/platforms/android/performance/instrumentation/perf-v2) feature flag and [App Start Profiling](/platforms/android/profiling/#app-start-profiling) must also be enabled in the SDK, e.g.:
+- [Performance-V2](/platforms/android/performance/instrumentation/perf-v2) feature flag (`<8.0.0`) and [App Start Profiling](/platforms/android/profiling/#app-start-profiling) must also be enabled in the SDK, e.g.:
 
 ```java {filename:MyApplication.java}
 import io.sentry.android.core.SentryAndroid;
@@ -59,23 +59,15 @@ The charts display the following metrics (using cold starts as an example):
 
 - Average Cold Start
     - The overall time it takes your application to start, compared by release.
-- Top Screen Cold Start
-    - The time it takes for individual screens to start, compared by release. This chart syncs with the sort order in the table below it.
-- Count
-    - The number of starts occurring in the selected time range for the releases. This gives you an idea of how statistically significant the aggregated data is.
+- Cold Start Device Distribution
+    - The average cold start time grouped by [device class](/concepts/search/searchable-properties/#device-classification) (high, medium, low, or unknown).
 
 **Reasons Why You Might Not Be Seeing Any Data:**
 
 - You don’t have any transactions with op `ui.load`
 - Your SDKs don’t meet the minimum SDK requirements
 
-## Screen Summary Page
-
-![Example of Screen Summary](./img/app-starts-screen-summary.png)
-
-To get additional information about any of your application’s screens, click on them to get to the **Screen Summary** page. Here, you’ll see your average start duration broken down by release and [device class](/concepts/search/searchable-properties/#device-classification) (high, medium, low, or unknown). This will help you understand how users with different device performance levels are being affected.
-
-The table below the chart shows spans that have changed from one release to the next and allows you to filter for specific span operations and device classes. Being able to narrow down to specific event samples helps debug slow starts.
+The table at the bottom shows spans that have changed from one release to the next and allows you to filter for specific span operations and device classes. Being able to narrow down to specific event samples helps debug slow starts.
 
 Clicking the "By Event" toggle in the top right corner of this table will show you events split by release and you'll be able to see overall changes in start times between the two releases you've selected.