Firebase Performance: qué es, métricas y cómo rastrear

Qué es Firebase Performance Monitoring

Firebase Performance Monitoring es un SDK y una plataforma en la nube para recopilar, agregar y visualizar métricas de rendimiento de aplicaciones móviles. El SDK se integra en la aplicación e instrumenta automáticamente puntos clave: el ciclo de vida de Activity (Android) o ViewController (iOS), las solicitudes de red a través de URLSession (iOS) u OkHttp (Android), y las llamadas al sistema. Los datos recopilados se envían al servidor de Firebase, donde se agregan por versión de la aplicación, dispositivo, país y otros atributos.

La arquitectura del SDK de Performance se basa en el principio de overhead mínimo: la instrumentación agrega no más del 1–2% al tiempo de ejecución de las operaciones medidas. Los datos se recopilan de forma asíncrona y se almacenan en búfer en el dispositivo antes de enviarlos, lo que elimina cualquier impacto en el rendimiento del hilo de la UI. Los datos se envían según un horario (por defecto cada 30 minutos) o cuando el búfer alcanza los 100 KB.

La diferencia clave entre Firebase Performance y los perfiladores de Android Studio (CPU Profiler) o Xcode Instruments es el monitoreo en producción. Firebase Performance recopila datos de dispositivos reales de usuarios, no solo de dispositivos de desarrolladores. Esto permite detectar problemas que solo ocurren en modelos específicos, versiones de SO o regiones particulares: problemas que no se pueden reproducir en un entorno controlado.

Cómo el SDK recopila datos sin cambios de código

La instrumentación automática es la característica principal de Firebase Performance. Para Android, el SDK registra automáticamente ActivityLifecycleCallbacks y mide el tiempo entre onCreate y onResume (tiempo de renderizado de pantalla). Para iOS, hace swizzle de los métodos viewDidLoad y viewDidAppear. Las solicitudes de red se interceptan a nivel de OkHttpInterceptor (Android) o NSURLProtocol (iOS). El desarrollador no necesita agregar llamadas start/stop para las métricas estándar.

Habilitar y deshabilitar el SDK de Performance se gestiona a través del complemento Google Services (Android) o Info.plist (iOS). Para depuración, puede habilitar el registro verbose del SDK de Performance, que muestra qué métricas se están recopilando y enviando. En producción, se recomienda mantener el registro en nivel de advertencia para evitar saturar los registros con información innecesaria. Para proyectos en Flutter o React Native, la instrumentación automática puede ser limitada; más detalles en la sección de ejemplos de código.

Límites gratuitos y precios

Firebase Performance está disponible en el nivel gratuito Spark sin límites en la cantidad de seguimientos o volumen de datos. El nivel pago Blaze tampoco cobra por Performance Monitoring — es uno de los pocos servicios de Firebase que es completamente gratuito en ambos niveles. Solo hay una limitación: los datos se almacenan durante 30 días (en Spark) y hasta 365 días (en Blaze). Para análisis a largo plazo, exporte los datos mediante BigQuery export.

Sin costo hace que Firebase Performance sea una opción ideal para cualquier proyecto, desde un prototipo hasta una aplicación empresarial con millones de usuarios. El único gasto es el tráfico saliente del SDK de Performance, pero es insignificante en comparación con otras operaciones de red de la aplicación (menos de 1 MB por mes por dispositivo). BigQuery export cobra por almacenamiento y consultas, pero el SDK de Performance en sí es gratuito.

Métricas automáticas: qué se mide sin código

Firebase Performance recopila automáticamente cinco categorías de métricas sin una sola línea de código: tiempo de inicio de la aplicación, solicitudes HTTP lentas, velocidad de renderizado de pantallas, uso de memoria (solo Android) y frecuencia de cuadros (solo Android). Estas métricas están disponibles en la consola de Firebase inmediatamente después de conectar el SDK y la primera sesión de usuario.

Tiempo de inicio de la aplicación — el tiempo desde el inicio del proceso hasta que la UI está completamente lista para la interacción. Se divide en inicio en frío (la aplicación se inicia desde cero) e inicio en cálido (la aplicación se reanuda desde el estado de fondo). El inicio en frío incluye la carga de archivos DEX, la inicialización de campos estáticos, la llamada a Application.onCreate y Activity.onCreate. Firebase clasifica automáticamente el tipo de inicio y muestra la distribución del tiempo para cada tipo.

Tiempo de renderizado de pantalla — el tiempo desde el inicio de la carga de la pantalla (onCreate para Android, viewDidLoad para iOS) hasta que la pantalla está lista para la interacción (onResume, viewDidAppear). Firebase agrega datos por cada pantalla (por nombre de clase o nombre de pantalla personalizado), lo que permite identificar qué pantalla carga más tiempo. Para Android, también se miden los fotogramas perdidos: la cantidad de fotogramas omitidos durante el renderizado de la pantalla (jank).

Solicitudes de red (HTTP/HTTPS)

El SDK de Performance intercepta y mide automáticamente cada solicitud HTTP/HTTPS enviada desde la aplicación a través de URLSession, OkHttp o URLConnection. Para cada solicitud, se registran: URL (ruta sin parámetros de consulta por seguridad), método HTTP, código de respuesta, tamaño de respuesta en bytes, duración de la solicitud y velocidad de conexión (WiFi, Cellular). Los datos se agregan en el panel de Solicitudes de red de la consola de Firebase.

Solicitudes lentas — solicitudes cuya duración supera un umbral establecido. Por defecto, el umbral de solicitud lenta es de 4000 ms. Esta métrica es fundamental para identificar problemas del backend: si después de una actualización del backend, la cantidad de solicitudes lentas crece del 1% al 15%, es una señal para el análisis inmediato de los registros del servidor. Los usuarios no esperarán más de 5 segundos por una respuesta — los datos de Firebase muestran que el 53% de los usuarios cierran la aplicación si una solicitud tarda más de 3 segundos.

Limitaciones de la instrumentación automática

Limitaciones de iOS: en iOS, el SDK de Performance no puede medir fotogramas perdidos (esta es una API privada). Para medir jank en iOS, use MetricKit o CADisplayLink. Además, en iOS, el SDK no intercepta solicitudes realizadas a través de clientes HTTP de terceros que no usan URLSession (por ejemplo, SwiftNIO). Para estos casos, use seguimientos personalizados con atributos HTTP.

Limitaciones de Android: en Android, la medición automática de memoria solo está disponible en dispositivos con Android 8.0+ (API 26+). Para versiones anteriores, use seguimientos personalizados con datos obtenidos a través de Debug.getMemoryInfo(). Además, el SDK no intercepta conexiones WebSocket — requieren seguimientos separados. A pesar de estas limitaciones, las métricas automáticas cubren el 80% de las necesidades de monitoreo de rendimiento.

Seguimientos personalizados y atributos HTTP

Los seguimientos personalizados (custom traces) son intervalos de tiempo con nombre que el desarrollador crea manualmente para medir el rendimiento de escenarios específicos: cargar un feed de noticias, procesar una imagen, sincronizar datos, ejecutar una consulta compleja a la base de datos. Los seguimientos personalizados complementan las métricas automáticas y permiten medir exactamente aquellos segmentos de código que el desarrollador considera críticos para el rendimiento.

Cada seguimiento tiene un nombre (máximo 100 caracteres) y puede contener hasta 5 métricas personalizadas — valores numéricos registrados dentro del seguimiento. Por ejemplo, en un seguimiento "image_processing", puede medir métricas como "original_file_size" y "processed_file_size". Las métricas se muestran en la consola de Firebase como distribuciones (mín, máx, promedio, percentiles), lo que permite analizar no solo la duración sino también las características de la operación.

Atributos HTTP — un tipo especial de seguimiento personalizado para solicitudes de red que no fueron interceptadas automáticamente por el SDK (por ejemplo, a través de WebSocket o bibliotecas de terceros). Los atributos HTTP incluyen URL, método HTTP, código de respuesta y tamaño de respuesta. Firebase los muestra en la sección de Solicitudes de red junto con las solicitudes recopiladas automáticamente, proporcionando una imagen unificada de la interacción de red.

Cuándo usar seguimientos personalizados

Los seguimientos personalizados son indispensables para medir: tiempo de carga de datos desde la base de datos local (Room, CoreData), duración de cálculos complejos (cifrado, compresión), rendimiento de animaciones y transiciones, tiempo de respuesta de SDKs de terceros (mapas, pagos, analíticas). Para cada escenario de este tipo, cree un seguimiento, envuelva el código medido en start/stop y agregue atributos para la segmentación posterior.

No abuse de los seguimientos personalizados. Cada seguimiento agrega un consumo adicional de batería y tráfico. Se recomienda no más de 10 a 15 seguimientos activos en la versión de producción de la aplicación. Para depuración, puede agregar más seguimientos, pero antes del lanzamiento, desactive los excesivos mediante Remote Config (use el indicador performance_tracing_enabled). Esto permite habilitar el rastreo detallado solo para usuarios o sesiones seleccionados.

Atributos de seguimiento para segmentación

Los atributos personalizados son pares clave-valor que se pueden agregar a un seguimiento para su posterior filtrado en la consola de Firebase. Por ejemplo, para el seguimiento "feed_load", puede agregar atributos como "feed_type" (main, explore, following) y "cache_status" (cold, warm). En la consola, los datos del seguimiento se pueden filtrar por estos atributos para determinar qué tipo de feed carga más lentamente.

Limitaciones: cada seguimiento puede tener hasta 5 atributos personalizados. Los valores de los atributos son cadenas de hasta 100 caracteres. Los atributos deben establecerse antes de que comience el seguimiento; cambiar un atributo después del inicio se ignora. Esta limitación está relacionada con el rendimiento: fijar atributos después del inicio requeriría sincronización adicional.

Umbrales de rendimiento y alertas

Los umbrales (thresholds) son valores límite configurables para las métricas, al superarlos Firebase Performance genera una advertencia. Los umbrales se establecen en la consola de Firebase (Performance > Thresholds) para cada métrica automática: tiempo de inicio de la aplicación (frío/cálido), tiempo de renderizado de pantalla, solicitudes HTTP lentas, tiempo de respuesta HTTP. Puede establecer umbrales globales para todas las versiones de la aplicación o específicos para versiones particulares.

Las alertas (alerts) son notificaciones automáticas que Firebase envía cuando se supera un umbral. Las alertas se pueden configurar por correo electrónico, webhook de Slack, PagerDuty o Cloud Functions (para manejo personalizado). Cada alerta contiene: nombre de la métrica, valor actual, valor umbral, versión de la aplicación, segmento (dispositivo, país). Las alertas permiten responder a la degradación del rendimiento antes de que sea notable para los usuarios.

Umbrales recomendados según el estándar de la industria (Google I/O 2025): inicio en frío — menos de 2 segundos, inicio en cálido — menos de 1 segundo, renderizado de pantalla — menos de 500 ms, duración de solicitud HTTP — menos de 3000 ms (percentil 95), proporción de solicitudes lentas — menos del 5%. Para aplicaciones altamente competitivas (Social, E-commerce), los umbrales objetivo pueden ser más estrictos: inicio en frío < 1.5 segundos, HTTP < 1000 ms.

Configuración de umbrales en la consola de Firebase

En la consola de Firebase, vaya a la sección Performance, abra la pestaña Thresholds. Para cada métrica, establezca el valor umbral deseado y el porcentaje de usuarios que debería verse afectado por la superación. Por ejemplo: "considerar el inicio en frío como lento si supera los 2 segundos para más del 10% de los usuarios". Firebase mostrará los valores actuales de las métricas y el historial de superaciones para ayudar a elegir umbrales realistas.

Importante: los umbrales no afectan la recopilación de datos, solo controlan la generación de notificaciones. Si el umbral es demasiado bajo (por ejemplo, inicio en frío 1 segundo, mientras que el 50% de los dispositivos se inician en 3 segundos), las alertas llegarán constantemente y se convertirán en "ruido" que los desarrolladores dejarán de notar. Establezca umbrales basados en el rendimiento actual, luego ajústelos gradualmente a medida que optimice la aplicación.

Panel de rendimiento en la consola de Firebase

El panel de rendimiento muestra las métricas clave como series temporales desglosadas por versión de la aplicación, dispositivo, país, tipo de conexión y versión del SO. Para cada métrica, están disponibles: promedio, mediana, percentil 95, percentil 99. El percentil 95 es la métrica más informativa para la evaluación del rendimiento, ya que muestra cómo funciona la aplicación en dispositivos débiles, ignorando valores atípicos.

El panel admite la comparación de versiones: seleccione dos versiones de la aplicación (actual y anterior) para la comparación visual de métricas. Si después de una actualización, el percentil 95 del tiempo de inicio aumentó de 2.1 a 3.4 segundos — la regresión es obvia, y necesita encontrar el commit que causó la ralentización. Firebase Performance se integra con GitHub, GitLab y Bitbucket, lo que permite vincular cambios de métricas con commits específicos.

Ejemplos de código para Performance Monitoring

Veamos ejemplos de integración de Firebase Performance Monitoring en una aplicación Android con Kotlin. El código demuestra la creación de un seguimiento personalizado para medir la carga del feed de noticias, la adición de un atributo HTTP para una solicitud no interceptada automáticamente y el uso de Trace para medir el tiempo de procesamiento de imágenes. Todos los ejemplos tienen en cuenta la capacidad de deshabilitar el rastreo mediante Remote Config.

Antes de usar, agregue la dependencia: implementation("com.google.firebase:firebase-perf") a través de Firebase BOM. Para la instrumentación automática, no se requiere configuración adicional — el SDK intercepta las operaciones estándar automáticamente después de agregar la dependencia.

Seguimiento personalizado para carga de feed

El primer ejemplo — medición del tiempo de carga del feed de noticias desde el servidor. El seguimiento envuelve la operación asíncrona fetchFeed, que obtiene datos de la red y analiza JSON. Se han agregado atributos personalizados al seguimiento: fuente de datos (caché o red) y la cantidad de publicaciones recibidas. Esto permite segmentar los datos y comprender en qué condiciones el feed carga más lentamente.

suspend fun loadFeedWithTrace(source: String) {
    val trace = Firebase.performance
        .newTrace("feed_load")
    trace.putAttribute("source", source)

    try {
        trace.start()
        val feed = fetchFeed()
        trace.putMetric(
            "items_count",
            feed.size.toLong()
        )
    } finally {
        trace.stop()
    }
}

La función loadFeedWithTrace toma un parámetro source ("cache" o "network"), que se usa como atributo del seguimiento. Después de que la operación asíncrona se completa, el seguimiento se detiene en un bloque finally, lo que garantiza la detención incluso en caso de excepción. La métrica items_count permite analizar cómo la cantidad de publicaciones afecta el tiempo de carga. En la consola de Firebase, puede filtrar los seguimientos por el atributo source y ver que la carga desde la red es 3 veces más lenta que desde la caché.

Atributo HTTP para solicitud no estándar

El segundo ejemplo — atributo HTTP para una solicitud realizada a través de WebSocket (no interceptada automáticamente). Se utiliza la clase HttpMetric, que permite registrar manualmente una solicitud URL, su método, código de respuesta y tamaño. Firebase mostrará esta solicitud en la sección de Solicitudes de red junto con las interceptadas automáticamente.

suspend fun sendWithHttpMetric() {
    val metric = Firebase.performance
        .newHttpMetric(
            "https://api.example.com/data",
            FirebasePerformance.HttpMethod.POST
        )
    metric.start()

    try {
        val response = webSocketSend()
        metric.setHttpResponseCode(response.code)
        metric.setRequestPayloadSize(1024)
        metric.setResponsePayloadSize(
            response.body.length.toLong()
        )
    } finally {
        metric.stop()
    }
}

En el ejemplo, sendWithHttpMetric usa newHttpMetric para registrar una llamada HTTP no estándar. El SDK no la intercepta automáticamente, por lo que el desarrollador establece manualmente la URL, el método, el código de respuesta y los tamaños. Es importante establecer la URL sin parámetros de consulta (por seguridad y agregación) — es decir, /data, no /data?token=abc. Firebase agrupa automáticamente patrones de URL idénticos.

Medición del tiempo de procesamiento de imágenes

El tercer ejemplo demuestra la medición del tiempo de procesamiento de imágenes (compresión, cambio de tamaño) mediante un seguimiento personalizado. En este caso, el seguimiento envuelve una operación síncrona, pero para producción use corrutinas o RxJava para evitar bloquear el hilo de la UI.

fun compressImage(bitmap: Bitmap): ByteArray {
    val trace = Firebase.performance
        .newTrace("image_compression")
    trace.putAttribute(
        "format", "JPEG"
    )
    trace.start()

    val stream = ByteArrayOutputStream()
    bitmap.compress(
        Bitmap.CompressFormat.JPEG, 80, stream
    )
    val result = stream.toByteArray()
    trace.putMetric(
        "output_size_kb",
        result.size / 1024.toLong()
    )
    trace.stop()
    return result
}

La función compressImage mide el tiempo de compresión de imagen a JPEG con calidad del 80%. El atributo format permite comparar el tiempo de compresión JPEG versus WebP en el futuro. La métrica output_size_kb muestra qué tan eficiente es la compresión. En la consola de Firebase, puede ver la distribución: en dispositivos débiles (Android de gama baja), la compresión toma 4 veces más tiempo que en los buques insignia, lo que podría ser la causa de retrasos al cargar imágenes al servidor.

Cómo mejorar el rendimiento basado en datos

Firebase Performance proporciona datos pero no ofrece soluciones listas. Analizar métricas requiere comprender las causas típicas de degradación del rendimiento para cada métrica. Veamos los principales patrones de degradación y cómo diagnosticarlos usando los datos de Performance Monitoring. Enfoque: encuentre una anomalía en una métrica → verifique las causas típicas → aplique la optimización → verifique el resultado después de una semana.

Inicio en frío lento (> 2 segundos): causas — inicialización pesada de SDK en Application.onCreate (analíticas, informes de crash, SDK de mapas), carga de recursos grandes (fuentes, temas), operaciones síncronas en el hilo principal al inicio. Soluciones: inicialización diferida de SDK, carga diferida de recursos, uso de SplashScreen API (Android 12+) para mostrar un marcador de posición durante la inicialización. Firebase Performance mostrará qué versión de la aplicación comenzó a ralentizarse — verifique qué dependencias se agregaron o actualizaron.

Renderizado de pantalla lento (> 500 ms): causas — jerarquía de Vista compleja (ConstraintLayout anidado, múltiples Fragment), carga de datos en el hilo de la UI (red o disco), operaciones de dibujo pesadas (imágenes grandes, Vistas personalizadas). Soluciones: optimizar la jerarquía de diseño (Layout Inspector en Android Studio), descargar datos al hilo de fondo, almacenar en caché imágenes mediante Glide o Coil. Use el filtro de Renderizado de pantalla en Firebase para encontrar la pantalla más lenta y optimizarla primero.

Optimización de solicitudes de red

Solicitudes HTTP lentas (> 3 segundos): causas — servidor lento, payloads grandes, falta de almacenamiento en caché, protocolo subóptimo (HTTP/1.1 en lugar de HTTP/2), resolución DNS. Soluciones: verifique el lado del servidor (tiempo de actividad, latencia), reduzca el tamaño de la respuesta (paginación, GraphQL, protobuf en lugar de JSON), habilite el almacenamiento en caché mediante cabeceras HTTP (Cache-Control), use OkHttp Interceptor para agregar tiempos de espera y lógica de reintento.

Firebase Performance muestra la distribución del tiempo de la solicitud: resolución DNS, handshake TCP, handshake TLS, envío de solicitud, recepción de respuesta. Si la mayor parte del tiempo se gasta en DNS — use precarga de DNS (OkHttp DNS-over-HTTPS). Si en TLS — use reanudación de sesión y ajuste los conjuntos de cifrado. Si en recepción de respuesta — verifique el tamaño de la respuesta y la velocidad de red del usuario. Los datos de Firebase permiten localizar el problema a nivel de protocolo, en lugar de simplemente decir "la solicitud es lenta".

Integración de Remote Config para deshabilitar el rastreo

Para producción, se recomienda agregar un indicador de Remote Config performance_tracing_enabled, que permite deshabilitar de forma remota los seguimientos personalizados. Si el SDK de Firebase Performance en el cliente genera demasiados datos o afecta el rendimiento (en dispositivos débiles), puede deshabilitar los seguimientos para todos los usuarios, dejando solo las métricas automáticas, que tienen un overhead mínimo.

Ejemplo de lógica: al iniciar la aplicación, verifique el parámetro de Remote Config performance_tracing_enabled. Si es false — todas las llamadas a Firebase.performance.newTrace() devuelven un objeto stub que no recopila datos. Esto se implementa a través de una clase envoltorio que verifica el indicador antes de crear un seguimiento. Este enfoque permite habilitar el rastreo detallado para usuarios específicos (probadores beta, desarrolladores) sin afectar a toda la audiencia.