Performance Monitoring — What It Is, Metrics, and Data Collection

What is Performance Monitoring

Performance monitoring is the practice of quantifying application behavior by collecting runtime metrics, memory usage, frame rate, and energy consumption. Unlike crash reporting, which only captures fatal failures, performance monitoring tracks gradual degradation: the app works but is slower than it should be.

According to Google (2024), 53% of users close an app if it takes longer than 3 seconds to load. Each additional second of delay reduces conversion by 20% on average across categories. This makes performance monitoring not just a technical practice but a business necessity for mobile products.

Modern performance monitoring covers four levels: client-side (iOS, Android), network (API requests, WebSocket), backend services, and infrastructure. In mobile development, the focus is on client-side metrics, since most performance issues arise on the user’s device.

Key Mobile App Metrics

For comprehensive monitoring, five metric groups must be tracked, each responsible for a different aspect of user experience. FPS (frames per second) shows the smoothness of animations and scrolling — values below 30 frames per second are perceived as lag by the human eye.

Time Metrics

Cold start time — from the moment of tapping the icon to full UI readiness. Hot start time — returning from the background. User action response time (tap-to-response). Startup time for Android is measured via ActivityManager, for iOS — via dyld and premain time. According to Firebase Performance, the median cold start time for the top 100 apps is 1.8 seconds.

Memory and CPU Metrics

RAM consumption should not exceed 80% of the available device capacity, otherwise the system starts offloading the app from the background. Memory footprint is tracked via Xcode Instruments (iOS) and Android Profiler. Memory leaks are detected by increasing consumption during repeated operations — for example, switching between screens.

Network Metrics

HTTP request execution time, response size, timeout frequency, and error rate. Network latency is particularly critical for mobile apps operating in unstable connection conditions (3G, subway, elevator, roaming). It is recommended to track p95 response time — it shows the experience of the most “heavy” users with the worst network conditions.

Real User Monitoring vs Synthetic Monitoring

Real User Monitoring (RUM) collects data from real user devices in a production environment. This method shows actual latencies experienced by users considering their devices, OS versions, network, and geolocation. RUM provides the most accurate performance picture but depends on which users are in the sample.

Synthetic Monitoring, on the other hand, executes predefined scenarios on test devices under controlled conditions. It allows detecting regression before it reaches users and reproducing problems in a consistent environment. Firebase Test Lab and BrowserStack provide synthetic tests on real devices without manual execution.

The optimal strategy is a combination of both approaches: synthetic tests catch regressions at the CI stage, while RUM provides the real picture in production. According to Datadog (2024), teams using both methods discover 35% more performance issues before they become incidents.

Setting Up Firebase Performance Monitoring

Firebase Performance Monitoring is a free tool from Google for collecting performance metrics on iOS and Android. It automatically measures app startup time, HTTP requests, and screen rendering without writing code. To set it up, simply add the SDK to your project and activate the Performance module in the Firebase console.

Automatic Metric Collection

After integrating the SDK, Firebase Performance automatically creates a trace for each HTTP request via URLSession (iOS) or OkHttp (Android). Screen rendering is measured for UIViewController and Activity, capturing the time from onCreate/viewDidLoad to the completion of first render. All metrics are aggregated in the Firebase console, broken down by app version, device, and country.

import com.google.firebase.perf.FirebasePerformance
import com.google.firebase.perf.metrics.Trace

class PaymentService {
    private val firebasePerf = FirebasePerformance.getInstance()

    fun processPayment(amount: Double) {
        val trace = firebasePerf.newTrace("payment-flow")
        trace.start()
        trace.putAttribute("amount", amount.toString())
        // payment processing
        trace.stop()
    }
}

The code creates a custom trace for the payment scenario with an amount attribute. Using this trace in the Firebase console, you can see the median and p95 payment execution time, grouped by app version and device.

HTTP Monitoring

Firebase automatically intercepts network requests and records the URL, response code, payload size, and execution time. For OkHttp on Android, automatic instrumentation works without additional configuration. Network requests are displayed in the console grouped by endpoint, allowing quick identification of a specific API slowdown.

Custom Traces for Business Logic

Standard metrics cover overall performance, but diagnosing business processes requires instrumenting specific scenarios. Custom traces allow measuring the execution time of authentication, news feed loading, image processing, or data synchronization.

Each custom trace should have a meaningful name in a “scenario-action” format and contain attributes for filtering. For example, an “image-upload” trace with “file_size” and “compression_quality” attributes will help identify the dependency of upload time on image size. It is recommended not to create more than 20 custom traces per screen — excessive instrumentation creates noise and complicates analysis.

import FirebasePerformance

func trackImageUpload(data: Data) {
    let trace = Performance.startTrace(name: "image-upload")
    trace?.setValue(data.count, forAttribute: "file_size")
    trace?.setValue("high", forAttribute: "compression")
    // image loading
    trace?.stop()
}

The Swift example creates a trace for image loading with file size and compression level attributes. In the Firebase console, these attributes become fields for grouping and filtering metrics.

Thresholds and Alerting

Collecting metrics without an alerting system is useless. Alerting should notify the team when metrics exceed acceptable boundaries, with thresholds divided into three levels: warning, critical, and outage. Each level determines the notification channel: warning — to the team Slack channel, critical — to PagerDuty for the on-call engineer, outage — mass notification to all stakeholders.

For mobile metrics, it is recommended to use dynamic percentile-based thresholds: p95 cold start time exceeding 4 seconds — critical alert. Static thresholds (e.g., CPU > 90%) work less effectively as they do not account for normal load fluctuations by time of day and day of week. Firebase Performance supports alert configuration via Firebase Console with notifications to Slack, PagerDuty, and email, with escalation options if unacknowledged.

According to the Incident Management Survey (2024), teams that set alerts based on percentiles rather than averages miss 45% fewer incidents. Average values smooth out outliers — p95 guarantees showing the worst-case scenario for users, regardless of time of day and seasonal load fluctuations.