Firebase Performance — what it is, monitoring tool and metrics

What is Firebase Performance Monitoring?

Firebase Performance Monitoring is a Google cloud service that collects and displays performance metrics for mobile applications. The service is part of the Firebase toolset and does not require separate payment — monitoring is available within the free Spark tier (limit of 500,000 events per day) and the paid Blaze tier. Firebase Performance automatically generates traces for standard scenarios: cold screen start, warm start, background HTTP requests.

The service architecture is built on two types of data: traces and metrics. A trace is a time interval with a start and end, within which execution duration is measured. A metric is a numerical value: response size, error rate, speed in bytes/sec. Each trace can contain multiple metrics. The SDK collects data on the device, buffers it and sends it to Firebase in the background with low-latency priority to avoid affecting user experience.

According to the Google I/O 2024 report, Firebase Performance is used in more than 2 million applications worldwide. The average time to detect a performance issue using Firebase Performance is 15 minutes after release if alerts are configured. Without monitoring, a similar problem is typically detected within 2-3 days through user complaints to support.

Difference from Firebase Crashlytics

Crashlytics tracks crashes and fatal errors — situations where the application terminates unexpectedly. Firebase Performance monitors performance in a running application: slow screens, long network requests, UI response delays. Crashlytics answers the question "why did the app crash?", while Performance answers "why is the app running slowly?". Both services integrate through a single SDK (Firebase Core) and data is displayed in adjacent sections of the Firebase console.

Percentile Metrics

Firebase Performance does not show average values — only percentiles: P50, P75, P90, P95, P99. This is critical for performance: average time hides outliers. If 99 users open a screen in 200 ms and one opens it in 20 seconds, the average would be ~400 ms, which looks acceptable. P99 will show 20 seconds — the real problem. Firebase displays percentiles on a timeline, allowing regression tracking with hourly precision.

How Firebase Performance Monitoring Works

Firebase Performance SDK is integrated into an application through standard integration: adding a dependency in Gradle (Android) or via CocoaPods (iOS). After Firebase initialization in code, the SDK automatically starts collecting metrics without additional configuration. An important principle is lazy collection: the SDK does not send data immediately but accumulates it and transmits batches under favorable network conditions.

For iOS, the SDK uses NSURLProtocol to intercept HTTP requests; for Android — OkHttp Interceptor. If the application does not use OkHttp, the SDK automatically wraps HttpURLConnection. Intercepted requests are enriched with metadata: Content-Type, response status, size in bytes, duration. All data is transmitted via HTTPS to the Firebase server with TLS 1.3 encryption.

One of the key requirements of Firebase Performance is to be the last plugin in the Gradle plugins list. If the order is violated, the SDK may not intercept all requests or may incorrectly measure startup time. Firebase recommends placing the plugin at the end of the plugins block, after Crashlytics and other Google Services plugins.

// build.gradle (Module: app) — correct plugin order
plugins {
    id "com.android.application"
    id "org.jetbrains.kotlin.android"
    id "com.google.gms.google-services"
    id "com.google.firebase.crashlytics"
    id "com.google.firebase.firebase-perf"  // last!
}

dependencies {
    implementation platform("com.google.firebase:firebase-bom:33.0.0")
    implementation "com.google.firebase:firebase-perf"
}

Automatic Traces: Screens, Startup, Network

Firebase Performance creates three types of automatic traces: screen trace (screen rendering time), app start trace (application startup time) and network request trace (HTTP requests). Screen trace for Android measures the time between the Activity.onCreate call and the completion of the first frame rendering. For iOS, the time between viewDidLoad and viewDidAppear is measured. Firebase automatically creates a trace for each screen, using the class name of the Activity or ViewController.

App start trace is divided into two types: cold start (the application starts from scratch, the process did not exist) and warm start (the application is restored from the background state). Cold start is the most critical metric because it includes initialization of all SDKs, loading DEX files and creating the first Activity. Firebase measures cold start from the moment the process starts to the full rendering of the first screen. According to Google recommendations, cold start should not exceed 500 ms for P50 and 2 seconds for P99.

Network request trace automatically records every HTTP request with metadata: URL, method, response code, response size, transfer speed. In the Firebase Performance console, you can filter requests by URL pattern — for example, show all requests to /api/v2/orders. For each pattern, response time percentiles and 4xx/5xx error rates are displayed. This allows quickly detecting degradation of a specific API without setting up individual alerts.

Screen Metrics in Detail

For screens, Firebase Performance additionally calculates the metric "frozen frames" — frames that took longer than 700 ms to render. Such UI freezes are perceived by the user as "the app froze". If a screen has more than 1% frozen frames, Firebase marks the metric as problematic. For Android, the SDK additionally collects the slow renders metric — frames longer than 16 ms (missing 60 FPS). The combination of screen trace and frozen frames provides a complete picture of both loading time and animation smoothness.

Custom Traces for Business Scenarios

Custom traces allow measuring the duration of any user scenario: placing an order, uploading an image to the cloud, synchronizing data. The developer explicitly specifies the start and end of the trace in code and sets the scenario name. Unlike automatic traces, custom traces provide full control over what is measured and allow adding attributes for filtering.

Each custom trace can contain attributes — key-value pairs that are added as metadata. Attributes help segment data: for example, you can track checkout time separately for "promo_user" and "regular_user". Firebase Performance supports up to 5 attributes per trace and up to 100 unique attribute values. Attributes are indexed and available for filtering in the Firebase console.

According to the Google I/O 2024 presentation, the Spotify team uses Firebase custom traces to monitor track switching time. This helped reduce the median switching time from 400 ms to 120 ms by identifying a bottleneck in audio buffer caching. The key insight came from filtering by the "device_model" attribute — the problem manifested only on Samsung devices with Android 13.

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

class CheckoutTracker {

    private val firebasePerf = FirebasePerformance.getInstance()

    fun trackCheckoutFlow(userId: String, promoApplied: Boolean) {
        val trace: Trace = firebasePerf.newTrace("checkout_flow")
        trace.putAttribute("promo_user", promoApplied.toString())
        trace.putAttribute("user_tier", "premium")
        trace.start()

        // Executing the checkout scenario
        validateCart()
        processPayment()
        confirmOrder()

        trace.stop()
    }
}

Integrating Firebase Performance into an Android Project

Integrating Firebase Performance into Android requires three steps: adding the google-services plugin, connecting the Firebase BOM (Bill of Materials) and adding the firebase-perf dependency. Firebase Performance automatically works on all Activities and fragments if they use AppCompatActivity. For Compose screens, Firebase recommends using custom traces since automatic screen trace does not support Compose directly.

An important nuance: the Firebase Performance Gradle plugin modifies the application bytecode at compile time. The plugin adds instrumenting code to every Activity and OkHttp client. This can increase build time by 5-10% and APK size by 200-400 KB. In debug builds, Firebase Performance is automatically disabled — this prevents metric distortion during local development. For forced enablement in debug, use the firebasePerformanceInstrumentationEnabled flag in the manifest.

Firebase Performance also supports MetricKit for iOS and Perfetto for Android — low-level system tracers. MetricKit provides data on frame rate, CPU and memory usage at the operating system level. Firebase aggregates this data and displays it in the same console where HTTP traces and screen traces are shown, combining system and application telemetry in one interface.

HTTP Requests with OkHttp

import okhttp3.OkHttpClient
import com.google.firebase.perf.network.FirebasePerfOkHttpClient

val client = OkHttpClient.Builder()
    .addInterceptor FirebasePerfOkHttpClient
    .build()

val request = Request.Builder()
    .url("https://api.example.com/orders")
    .build()

client.newCall(request).enqueue(object : Callback {
    override fun onFailure(call: Call, e: IOException) { /* handle */ }
    override fun onResponse(call: Call, response: Response) { /* handle */ }
})

Integrating Firebase Performance into an iOS Project

For iOS, Firebase Performance integration is done through CocoaPods or Swift Package Manager. After installing the FirebasePerformance and FirebaseCore pods, the SDK automatically starts collecting metrics. For intercepting HTTP requests, Firebase Performance iOS uses NSURLProtocol — a system mechanism that allows intercepting all URL loads in the application. The SDK registers its NSURLProtocol subclass at startup, and all requests through URLSession automatically fall under monitoring.

Limitation for iOS: Firebase Performance does not support automatic screen trace for SwiftUI. For SwiftUI applications, you must manually create custom traces by wrapping the View body in a start/stop block. Firebase is working on native SwiftUI support, but currently the SDK automatically traces only UIView controllers. For hybrid applications on UIKit + SwiftUI, it is recommended to create screens on UIKit and embed SwiftUI through UIHostingController.

Firebase Performance iOS also provides integration with MetricKit — an Apple framework that collects diagnostic data at the OS level. MetricKit sends daily reports with CPU, GPU, memory and frame rate metrics. Firebase Performance aggregates these reports and displays them in the console alongside custom traces, providing a complete picture of performance at both the application and system levels.

import FirebasePerformance

final class ImageUploadService {

    func uploadImage(_ data: Data, to url: URL) async throws {
        guard let trace = Performance.startTrace(name: "image_upload") else { return }
        trace?.setValue("image/jpeg", forAttribute: "content_type")
        trace?.setValue("\(data.count)", forAttribute: "file_size")

        var request = URLRequest(url: url)
        request.httpMethod = "POST"
        request.httpBody = data

        let (_, response) = try await URLSession.shared.data(for: request)
        guard let httpResponse = response as? HTTPURLResponse else { return }
        trace?.setValue("\(httpResponse.statusCode)",
                        forAttribute: "status_code")
        trace?.stop()
    }
}