Firebase Performance — qué es, herramienta de monitoreo y métricas

¿Qué es Firebase Performance Monitoring?

Firebase Performance Monitoring es un servicio en la nube de Google que recopila y muestra métricas de rendimiento de aplicaciones móviles. El servicio forma parte del conjunto de herramientas de Firebase y no requiere pago por separado: el monitoreo está disponible dentro del nivel gratuito Spark (límite de 500 000 eventos por día) y el nivel pago Blaze. Firebase Performance genera automáticamente trazos para escenarios estándar: inicio en frío de pantalla, inicio en cálido, solicitudes HTTP en segundo plano.

La arquitectura del servicio se basa en dos tipos de datos: traces (trazos) y metrics (métricas). Un trazo es un intervalo de tiempo con un inicio y un fin, dentro del cual se mide la duración de la ejecución. Una métrica es un valor numérico: tamaño de respuesta, tasa de errores, velocidad en bytes/seg. Cada trazo puede contener varias métricas. El SDK recopila datos en el dispositivo, los almacena en búfer y los envía a Firebase en segundo plano con prioridad de baja latencia para no afectar la experiencia del usuario.

Según el informe de Google I/O 2024, Firebase Performance se utiliza en más de 2 millones de aplicaciones en todo el mundo. El tiempo promedio para detectar un problema de rendimiento con Firebase Performance es de 15 minutos después del lanzamiento si las alertas están configuradas. Sin monitoreo, un problema similar se detecta típicamente en 2-3 días a través de quejas de usuarios al soporte.

Diferencia con Firebase Crashlytics

Crashlytics rastrea fallos y errores fatales — situaciones en las que la aplicación termina inesperadamente. Firebase Performance monitorea el rendimiento en una aplicación en ejecución: pantallas lentas, solicitudes de red largas, demoras en la respuesta de la UI. Crashlytics responde a la pregunta "¿por qué falló la aplicación?", mientras que Performance responde "¿por qué la aplicación funciona lentamente?". Ambos servicios se integran a través de un solo SDK (Firebase Core) y los datos se muestran en secciones adyacentes de la consola de Firebase.

Métricas de percentiles

Firebase Performance no muestra valores promedio — solo percentiles: P50, P75, P90, P95, P99. Esto es crítico para el rendimiento: el tiempo promedio oculta los valores atípicos. Si 99 usuarios abren una pantalla en 200 ms y uno la abre en 20 segundos, el promedio sería ~400 ms, lo que parece aceptable. P99 mostrará 20 segundos — el problema real. Firebase muestra los percentiles en una línea de tiempo, lo que permite rastrear regresiones con precisión por hora.

Cómo funciona Firebase Performance Monitoring

Firebase Performance SDK se integra en una aplicación mediante integración estándar: agregando una dependencia en Gradle (Android) o a través de CocoaPods (iOS). Después de la inicialización de Firebase en el código, el SDK comienza automáticamente a recopilar métricas sin configuración adicional. Un principio importante es la recopilación diferida: el SDK no envía datos inmediatamente, sino que los acumula y los transmite en lotes cuando las condiciones de red son favorables.

Para iOS, el SDK utiliza NSURLProtocol para interceptar solicitudes HTTP; para Android — OkHttp Interceptor. Si la aplicación no usa OkHttp, el SDK envuelve automáticamente HttpURLConnection. Las solicitudes interceptadas se enriquecen con metadatos: Content-Type, estado de respuesta, tamaño en bytes, duración. Todos los datos se transmiten a través de HTTPS al servidor de Firebase con cifrado TLS 1.3.

Uno de los requisitos clave de Firebase Performance es ser el último plugin en la lista de plugins de Gradle. Si se viola el orden, el SDK puede no interceptar todas las solicitudes o medir incorrectamente el tiempo de inicio. Firebase recomienda colocar el plugin al final del bloque de plugins, después de Crashlytics y otros plugins de Google Services.

// build.gradle (Module: app) — orden correcto de plugins
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"  // ¡último!
}

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

Trazos automáticos: pantallas, inicio, red

Firebase Performance crea tres tipos de trazos automáticos: screen trace (tiempo de renderizado de pantalla), app start trace (tiempo de inicio de la aplicación) y network request trace (solicitudes HTTP). El screen trace para Android mide el tiempo entre la llamada Activity.onCreate y la finalización del renderizado del primer fotograma. Para iOS, se mide el tiempo entre viewDidLoad y viewDidAppear. Firebase crea automáticamente un trazo para cada pantalla, usando el nombre de la clase Activity o ViewController.

App start trace se divide en dos tipos: inicio en frío (la aplicación se inicia desde cero, el proceso no existía) e inicio en cálido (la aplicación se restaura desde el estado de segundo plano). El inicio en frío es la métrica más crítica porque incluye la inicialización de todos los SDK, la carga de archivos DEX y la creación de la primera Activity. Firebase mide el inicio en frío desde el momento en que comienza el proceso hasta el renderizado completo de la primera pantalla. Según las recomendaciones de Google, el inicio en frío no debe exceder los 500 ms para P50 y 2 segundos para P99.

Network request trace registra automáticamente cada solicitud HTTP con metadatos: URL, método, código de respuesta, tamaño de respuesta, velocidad de transferencia. En la consola de Firebase Performance, puede filtrar solicitudes por patrón de URL — por ejemplo, mostrar todas las solicitudes a /api/v2/orders. Para cada patrón, se muestran los percentiles de tiempo de respuesta y las tasas de error 4xx/5xx. Esto permite detectar rápidamente la degradación de una API específica sin configurar alertas individuales.

Métricas de pantalla en detalle

Para las pantallas, Firebase Performance calcula adicionalmente la métrica "frozen frames" — fotogramas que tardaron más de 700 ms en renderizarse. Estos congelamientos de la UI son percibidos por el usuario como "la aplicación se congeló". Si una pantalla tiene más del 1% de frozen frames, Firebase marca la métrica como problemática. Para Android, el SDK también recopila la métrica de slow renders — fotogramas de más de 16 ms (perdiendo 60 FPS). La combinación de screen trace y frozen frames proporciona una imagen completa tanto del tiempo de carga como de la suavidad de las animaciones.

Trazos personalizados para escenarios de negocio

Trazos personalizados permiten medir la duración de cualquier escenario de usuario: realizar un pedido, cargar una imagen en la nube, sincronizar datos. El desarrollador especifica explícitamente el inicio y el fin del trazo en el código y establece el nombre del escenario. A diferencia de los trazos automáticos, los trazos personalizados brindan control total sobre lo que se mide y permiten agregar atributos para filtrar.

Cada trazo personalizado puede contener atributos — pares clave-valor que se agregan como metadatos. Los atributos ayudan a segmentar los datos: por ejemplo, puede rastrear el tiempo de pago por separado para "promo_user" y "regular_user". Firebase Performance admite hasta 5 atributos por trazo y hasta 100 valores de atributo únicos. Los atributos se indexan y están disponibles para filtrar en la consola de Firebase.

Según la presentación de Google I/O 2024, el equipo de Spotify utiliza trazos personalizados de Firebase para monitorear el tiempo de cambio entre canciones. Esto ayudó a reducir el tiempo de cambio medio de 400 ms a 120 ms al identificar un cuello de botella en el almacenamiento en caché del búfer de audio. La clave fue el filtrado por el atributo "device_model" — el problema se manifestaba solo en dispositivos Samsung con 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()

        // Ejecutando el escenario de pago
        validateCart()
        processPayment()
        confirmOrder()

        trace.stop()
    }
}

Integración de Firebase Performance en un proyecto Android

La integración de Firebase Performance en Android requiere tres pasos: agregar el plugin google-services, conectar el BOM (Bill of Materials) de Firebase y agregar la dependencia firebase-perf. Firebase Performance funciona automáticamente en todas las Activities y fragmentos si usan AppCompatActivity. Para pantallas Compose, Firebase recomienda usar trazos personalizados ya que el screen trace automático no admite Compose directamente.

Un matiz importante: el plugin de Gradle de Firebase Performance modifica el bytecode de la aplicación en tiempo de compilación. El plugin agrega código de instrumentación a cada Activity y cliente OkHttp. Esto puede aumentar el tiempo de compilación en un 5-10% y el tamaño del APK en 200-400 KB. En las compilaciones de depuración, Firebase Performance se desactiva automáticamente — esto evita la distorsión de métricas durante el desarrollo local. Para la activación forzada en depuración, use el indicador firebasePerformanceInstrumentationEnabled en el manifiesto.

Firebase Performance también admite MetricKit para iOS y Perfetto para Android — rastreadores de sistema de bajo nivel. MetricKit proporciona datos sobre la frecuencia de fotogramas, el uso de CPU y memoria a nivel del sistema operativo. Firebase agrega estos datos y los muestra en la misma consola donde se muestran los trazos HTTP y los screen traces, combinando la telemetría del sistema y de la aplicación en una sola interfaz.

Solicitudes HTTP con 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 */ }
})

Integración de Firebase Performance en un proyecto iOS

Para iOS, la integración de Firebase Performance se realiza a través de CocoaPods o Swift Package Manager. Después de instalar los pods FirebasePerformance y FirebaseCore, el SDK comienza automáticamente a recopilar métricas. Para interceptar solicitudes HTTP, Firebase Performance iOS utiliza NSURLProtocol — un mecanismo del sistema que permite interceptar todas las cargas de URL en la aplicación. El SDK registra su subclase de NSURLProtocol al iniciar, y todas las solicitudes a través de URLSession caen automáticamente bajo monitoreo.

Limitación para iOS: Firebase Performance no admite el screen trace automático para SwiftUI. Para aplicaciones SwiftUI, debe crear manualmente trazos personalizados envolviendo el cuerpo de la View en un bloque de inicio/fin. Firebase está trabajando en la compatibilidad nativa con SwiftUI, pero actualmente el SDK rastrea automáticamente solo los controladores UIView. Para aplicaciones híbridas en UIKit + SwiftUI, se recomienda crear pantallas en UIKit e incrustar SwiftUI a través de UIHostingController.

Firebase Performance iOS también proporciona integración con MetricKit — un framework de Apple que recopila datos de diagnóstico a nivel del SO. MetricKit envía informes diarios con métricas de CPU, GPU, memoria y frecuencia de fotogramas. Firebase Performance agrega estos informes y los muestra en la consola junto con los trazos personalizados, proporcionando una imagen completa del rendimiento tanto a nivel de aplicación como de sistema.

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()
    }
}