# Application Performance

> Track Core Web Vitals on web and app startup / screen load times on mobile. Analyze traffic patterns and optimize performance using real user data.

Source: https://last9.io/docs/discover-applications-performance/

![Applications Performance](../../../../../assets/content/docs/discover/applications/performance/performance.png)

The Performance tab in [Discover Applications](https://app.last9.io/applications) shows loading-speed, traffic, and responsiveness metrics for your app. The surfaced metrics depend on platform: **Core Web Vitals** for web apps, **app startup and screen-load times** for mobile apps.

## Accessing Performance Monitoring

    1. Navigate to [Discover > Applications](https://app.last9.io/applications) in Last9
    2. Select the Performance tab (active by default)
    3. Choose your version and environment from the top filters
    4. Set your desired time range using the date picker

## Dashboard Components

### Views / Screens Over Time

Track traffic volume across your selected time range. The chart is labeled **Views Over Time** for web apps (each view = a page load) and **Screens Over Time** for mobile apps (each screen = a screen/activity/view-controller transition).

Use it to:

- Identify peak usage times and traffic spikes
- Detect unusual drops that might indicate an outage or release regression
- Correlate performance with traffic volume

### Top Paths / Top Screens

The "Top 10" list shows the most-trafficked entities:

- **Web**: top URL paths (`path` attribute) by view count
- **Mobile**: top screens (`screen.name` attribute) by load count

Prioritize optimization on the entries that drive the most traffic.

### Web Vitals (web only)

For web apps, Core Web Vitals are surfaced as cards with P75, P90, and P99 percentile values — TTFB, LCP, FCP, CLS, INP. See [Core Web Vitals Explained](#core-web-vitals-explained) below.

### Mobile Vitals (mobile only)

For mobile apps, three span-duration metrics are surfaced at P75:

- **Cold Start** — time from app process launch to first usable frame. Captured as the `AppStart` span with `start.type=cold`.
- **Warm Start** — time from foreground resume to usable frame (app process already running). `AppStart` span with `start.type=warm`.
- **Screen Load Time** — time to render each screen after navigation. Captured from the screen lifecycle `Created` span.

### Geographic Map (web only)

A map of where your traffic originates, overlaid with performance buckets by region. Currently rendered only for web apps — mobile SDKs don't emit geo-level data yet.

## Grouping and Filtering

### Group by options

Click the Group by button to segment your data. Available options depend on platform:

**Web:**

- **Browser** — Chrome, Firefox, Safari, etc.
- **Platform** — Windows, macOS, iOS, Android (browser platform)
- **Screen Size** — desktop vs mobile vs tablet
- **Network Type** — 4G, WiFi, etc.
- **Device Type** — mobile vs desktop
- **Error Type**
- **City**, **Country**

**Mobile:**

- **OS Version** — specific Android/iOS version
- **Device Brand** — Samsung, Apple, etc.
- **Device Model**
- **App Version**
- **Network Type**
- **Error Type**
- **City**, **Country**

### Path and Attribute Filtering

Use the search bar to filter by specific pages (or screens) or user attributes. The operators below are available for `path` on web; on mobile, use the same operators against `screen.name` or `view.name`.

#### Path Filtering (web) / Screen Filtering (mobile)

Filter by URL paths using these operators:

- `=` (equals): Exact path match
- `exists`: Pages where the path field is present
- `not exists`: Pages missing path information
- `starts with`: Paths beginning with specific text
- `ends with`: Paths ending with specific text
- `contains`: Paths containing specific text
- `does not contain`: Paths excluding specific text

Example: `path starts with /api` to analyze API endpoint performance

#### Attribute Filtering

Filter by collected attributes including:

**Page Attributes:**

- `origin`: Page origin (protocol + hostname)
- `page.hash`: Current page hash
- `page.hostname`: Current page hostname
- `page.route`: Current page route/path
- `page.search`: Current page search/query string
- `page.url`: Current page URL
- `url.path`: Current page path
- `path`: Folded path (for navigation)

**Web Vitals Attributes:**

For each web vital metric (CLS, FCP, LCP, TTFB, INP), these attributes are available:

- `web_vital.<metric>.id`: Unique ID for the metric
- `web_vital.<metric>.value`: Value of the metric
- `web_vital.<metric>.timestamp`: When the metric was recorded
- `web_vital.<metric>.rating`: Rating ('good', 'needs-improvement', 'poor')
- `web_vital.<metric>.delta`: Delta value
- `web_vital.<metric>.entries_count`: Number of entries
- `web_vital.navigation_type`: Navigation type ('reload', 'navigate')

## Core Web Vitals Explained (web)

### Time To First Byte (TTFB)

- **Definition**: Measures server responsiveness—the time between a user's request and when the first byte of response arrives
- **Performance Thresholds**:
  - 🟢 Good: ≤ 800ms
  - 🟡 Needs Improvement: ≤ 1.8s
  - 🔴 Poor: > 1.8s
- **What It Means**: High TTFB indicates server-side performance issues like slow database queries, inefficient processing, or network latency
- **Optimization Focus**: Server performance, database optimization, CDN usage, caching strategies

### Largest Contentful Paint (LCP)

- **Definition**: Tracks when the main content becomes visible—specifically when the largest content element finishes rendering
- **Performance Thresholds**:
  - 🟢 Good: ≤ 2.5s
  - 🟡 Needs Improvement: ≤ 4s
  - 🔴 Poor: > 4s
- **What It Means**: LCP directly impacts perceived loading performance. Users judge speed based on when they see main content
- **Optimization Focus**: Image optimization, lazy loading, critical resource prioritization, server response times

### First Contentful Paint (FCP)

- **Definition**: Measures when users first see any content—the time until the first text, image, or element appears
- **Performance Thresholds**:
  - 🟢 Good: ≤ 1.8s
  - 🟡 Needs Improvement: ≤ 3s
  - 🔴 Poor: > 3s
- **What It Means**: FCP indicates how quickly users perceive your page is starting to load
- **Optimization Focus**: Critical CSS, font loading strategies, eliminating render-blocking resources

### Cumulative Layout Shift (CLS)

- **Definition**: Quantifies visual stability by measuring unexpected layout shifts during page loading
- **Performance Thresholds**:
  - 🟢 Good: ≤ 0.1
  - 🟡 Needs Improvement: ≤ 0.25
  - 🔴 Poor: > 0.25
- **What It Means**: High CLS creates frustrating experiences when elements move unexpectedly as users try to interact
- **Optimization Focus**: Size attributes for images/videos, space reservation for dynamic content

### Interaction to Next Paint (INP)

- **Definition**: Measures interface responsiveness by tracking time between user interactions and the next visual update
- **Performance Thresholds**:
  - 🟢 Good: ≤ 200ms
  - 🟡 Needs Improvement: ≤ 500ms
  - 🔴 Poor: > 500ms
- **What It Means**: INP affects how responsive your application feels to user interactions
- **Optimization Focus**: JavaScript optimization, reducing main thread work, efficient event handlers

## Mobile Vitals Explained (mobile)

### Cold Start

- **Definition**: Time from app process launch to the first usable frame. This is what users experience when they tap the app icon after it has been fully killed (or after a reboot / first install).
- **Captured as**: span named `AppStart` with attribute `start.type=cold`. The span's duration is the cold-start time.
- **What it means**: High cold-start times typically point to slow app initialization — heavy work on the main thread during `Application.onCreate()` / `AppDelegate didFinishLaunching` / Flutter engine startup.
- **Optimization focus**: defer non-critical SDK initialization, lazy-load heavy dependencies, audit work done during `onCreate` / app delegate launch.

### Warm Start

- **Definition**: Time from app foreground resume to the first usable frame when the app process is already running in the background.
- **Captured as**: `AppStart` span with `start.type=warm`.
- **What it means**: Warm start should be significantly faster than cold start (typically under 1s). If warm start is slow, foregrounding logic is doing too much work.
- **Optimization focus**: minimize work in `onResume` / `applicationWillEnterForeground` / `AppLifecycleState.resumed`.

### Screen Load Time

- **Definition**: Time to render a screen after navigating to it.
- **Captured as**: span emitted by the screen lifecycle (`Activity.onCreate` on Android, view controller lifecycle on iOS, `NavigatorObserver.didPush` on Flutter, `onStateChange` on React Navigation). Duration = time from navigation intent to first frame rendered.
- **What it means**: Slow screens indicate heavy work in view construction, synchronous data fetches, or expensive layout computation.
- **Optimization focus**: move blocking data fetches off the critical path, show skeleton UI, avoid layout thrashing.

## Best Practices

- **Regular Monitoring**: Check performance metrics weekly to catch regressions early
- **Focus on High-Impact Pages**: Prioritize optimization on pages with high traffic and poor performance
- **Monitor All Percentiles**: P99 shows what your worst-performing users experience
- **Correlate with Deployments**: Use version filtering to understand how releases affect performance
- **Set Performance Budgets**: Define acceptable thresholds for each metric and monitor against them
- **Use Grouping**: Segment by browser, device, or network to identify specific user experience issues

---

## Troubleshooting

Please get in touch with us on [Discord](https://discord.com/invite/Q3p2EEucx9) or [Email](mailto:support@last9.io) if you have any questions.