Skip to content
Last9
Book demo

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.

Applications Performance

The Performance tab in Discover 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 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 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 or Email if you have any questions.