Firebase Performance: o que é, métricas e como rastrear

O que é Firebase Performance Monitoring

Firebase Performance Monitoring é um SDK e plataforma em nuvem para coletar, agregar e visualizar métricas de desempenho de aplicativos móveis. O SDK é incorporado ao aplicativo e instrumenta automaticamente pontos-chave: o ciclo de vida da Activity (Android) ou ViewController (iOS), requisições de rede via URLSession (iOS) ou OkHttp (Android), e chamadas de sistema. Os dados coletados são enviados ao servidor Firebase, onde são agregados por versão do aplicativo, dispositivo, país e outros atributos.

A arquitetura do SDK de Performance é baseada no princípio de overhead mínimo: a instrumentação adiciona não mais que 1–2% ao tempo de execução das operações medidas. Os dados são coletados de forma assíncrona e armazenados em buffer no dispositivo antes do envio, eliminando qualquer impacto no desempenho da thread da UI. Os dados são enviados em um cronograma (por padrão a cada 30 minutos) ou quando o buffer atinge 100 KB.

A principal diferença entre o Firebase Performance e os profilers do Android Studio (CPU Profiler) ou Xcode Instruments é o monitoramento em produção. O Firebase Performance coleta dados de dispositivos reais de usuários, não apenas de dispositivos de desenvolvedores. Isso permite detectar problemas que ocorrem apenas em modelos específicos, versões de SO ou regiões particulares — problemas que não podem ser reproduzidos em um ambiente controlado.

Como o SDK coleta dados sem alteração de código

Instrumentação automática é a principal característica do Firebase Performance. Para Android, o SDK registra automaticamente ActivityLifecycleCallbacks e mede o tempo entre onCreate e onResume (tempo de renderização de tela). Para iOS, ele faz swizzle dos métodos viewDidLoad e viewDidAppear. As requisições de rede são interceptadas no nível OkHttpInterceptor (Android) ou NSURLProtocol (iOS). O desenvolvedor não precisa adicionar chamadas start/stop para métricas padrão.

Habilitar e desabilitar o SDK de Performance é gerenciado através do plugin Google Services (Android) ou Info.plist (iOS). Para depuração, você pode habilitar o log detalhado do SDK de Performance, que mostra quais métricas estão sendo coletadas e enviadas. Em produção, recomenda-se manter o log no nível de aviso para evitar poluir os logs com informações desnecessárias. Para projetos em Flutter ou React Native, a instrumentação automática pode ser limitada — mais detalhes na seção de exemplos de código.

Limites gratuitos e preços

Firebase Performance está disponível no nível gratuito Spark sem limites no número de rastreamentos ou volume de dados. O nível pago Blaze também não cobra pelo Performance Monitoring — é um dos poucos serviços Firebase que é completamente gratuito em ambos os níveis. Há apenas uma limitação: os dados são armazenados por 30 dias (no Spark) e até 365 dias (no Blaze). Para análise de longo prazo, exporte os dados via BigQuery export.

Sem custo torna o Firebase Performance uma escolha ideal para qualquer projeto — desde um protótipo até um aplicativo empresarial com milhões de usuários. A única despesa é o tráfego de saída do SDK de Performance, mas é insignificante comparado a outras operações de rede do aplicativo (menos de 1 MB por mês por dispositivo). O BigQuery export cobra por armazenamento e consultas, mas o SDK de Performance em si é gratuito.

Métricas automáticas: o que é medido sem código

Firebase Performance coleta automaticamente cinco categorias de métricas sem uma única linha de código: tempo de inicialização do aplicativo, requisições HTTP lentas, velocidade de renderização de telas, uso de memória (apenas Android) e taxa de quadros (apenas Android). Essas métricas estão disponíveis no console do Firebase imediatamente após conectar o SDK e a primeira sessão do usuário.

Tempo de inicialização do aplicativo — o tempo desde o início do processo até a UI estar completamente pronta para interação. É dividido em inicialização a frio (aplicativo inicia do zero) e inicialização a quente (aplicativo retoma do estado em segundo plano). A inicialização a frio inclui carregamento de arquivos DEX, inicialização de campos estáticos, chamada a Application.onCreate e Activity.onCreate. O Firebase classifica automaticamente o tipo de inicialização e mostra a distribuição de tempo para cada tipo.

Tempo de renderização de tela — o tempo desde o início do carregamento da tela (onCreate para Android, viewDidLoad para iOS) até o momento em que a tela está pronta para interação (onResume, viewDidAppear). O Firebase agrega dados por cada tela (por nome de classe ou nome de tela personalizado), permitindo identificar qual tela carrega por mais tempo. Para Android, também são medidos quadros perdidos — o número de quadros ignorados durante a renderização da tela (jank).

Requisições de rede (HTTP/HTTPS)

O SDK de Performance intercepta e mede automaticamente cada requisição HTTP/HTTPS enviada do aplicativo via URLSession, OkHttp ou URLConnection. Para cada requisição, são registrados: URL (caminho sem parâmetros de consulta por segurança), método HTTP, código de resposta, tamanho da resposta em bytes, duração da requisição e velocidade de conexão (WiFi, Celular). Os dados são agregados no painel de Requisições de Rede do console do Firebase.

Requisições lentas — requisições cuja duração excede um limite definido. Por padrão, o limite de requisição lenta é de 4000 ms. Essa métrica é crítica para identificar problemas de backend: se após uma atualização do backend o número de requisições lentas crescer de 1% para 15%, é um sinal para análise imediata dos logs do servidor. Os usuários não esperarão mais de 5 segundos por uma resposta — os dados do Firebase mostram que 53% dos usuários fecham o aplicativo se uma requisição demorar mais de 3 segundos.

Limitações da instrumentação automática

Limitações do iOS: no iOS, o SDK de Performance não pode medir quadros perdidos (esta é uma API privada). Para medir jank no iOS, use MetricKit ou CADisplayLink. Além disso, no iOS, o SDK não intercepta requisições feitas através de clientes HTTP de terceiros que não usam URLSession (por exemplo, SwiftNIO). Para esses casos, use rastreamentos personalizados com atributos HTTP.

Limitações do Android: no Android, a medição automática de memória está disponível apenas em dispositivos com Android 8.0+ (API 26+). Para versões mais antigas, use rastreamentos personalizados com dados obtidos através de Debug.getMemoryInfo(). Além disso, o SDK não intercepta conexões WebSocket — elas exigem rastreamentos separados. Apesar dessas limitações, as métricas automáticas cobrem 80% das necessidades de monitoramento de desempenho.

Rastreamentos personalizados e atributos HTTP

Rastreamentos personalizados (custom traces) são intervalos de tempo nomeados que o desenvolvedor cria manualmente para medir o desempenho de cenários específicos: carregar um feed de notícias, processar uma imagem, sincronizar dados, executar uma consulta complexa ao banco de dados. Os rastreamentos personalizados complementam as métricas automáticas e permitem medir exatamente aqueles segmentos de código que o desenvolvedor considera críticos para o desempenho.

Cada rastreamento tem um nome (máximo 100 caracteres) e pode conter até 5 métricas personalizadas — valores numéricos registrados dentro do rastreamento. Por exemplo, em um rastreamento "image_processing", você pode medir métricas como "original_file_size" e "processed_file_size". As métricas são exibidas no console do Firebase como distribuições (mín, máx, média, percentis), permitindo analisar não apenas a duração, mas também as características da operação.

Atributos HTTP — um tipo especial de rastreamento personalizado para requisições de rede que não foram interceptadas automaticamente pelo SDK (por exemplo, via WebSocket ou bibliotecas de terceiros). Os atributos HTTP incluem URL, método HTTP, código de resposta e tamanho da resposta. O Firebase os exibe na seção de Requisições de Rede junto com as requisições coletadas automaticamente, fornecendo uma imagem unificada da interação de rede.

Quando usar rastreamentos personalizados

Rastreamentos personalizados são indispensáveis para medir: tempo de carregamento de dados do banco de dados local (Room, CoreData), duração de cálculos complexos (criptografia, compressão), desempenho de animações e transições, tempo de resposta de SDKs de terceiros (mapas, pagamentos, analytics). Para cada cenário desse tipo, crie um rastreamento, envolva o código medido em start/stop e adicione atributos para segmentação posterior.

Não abuse dos rastreamentos personalizados. Cada rastreamento adiciona um consumo extra de bateria e tráfego. Recomenda-se não mais de 10 a 15 rastreamentos ativos na versão de produção do aplicativo. Para depuração, você pode adicionar mais rastreamentos, mas antes do lançamento, desative os excessivos via Remote Config (use a flag performance_tracing_enabled). Isso permite habilitar o rastreamento detalhado apenas para usuários ou sessões selecionados.

Atributos de rastreamento para segmentação

Atributos personalizados são pares chave-valor que podem ser adicionados a um rastreamento para filtragem posterior no console do Firebase. Por exemplo, para o rastreamento "feed_load", você pode adicionar atributos como "feed_type" (main, explore, following) e "cache_status" (cold, warm). No console, os dados do rastreamento podem ser filtrados por esses atributos para determinar qual tipo de feed carrega mais lentamente.

Limitações: cada rastreamento pode ter até 5 atributos personalizados. Os valores dos atributos são strings de até 100 caracteres. Os atributos devem ser definidos antes do início do rastreamento; alterar um atributo após o início é ignorado. Essa limitação está relacionada ao desempenho: fixar atributos após o início exigiria sincronização adicional.

Limiares de desempenho e alertas

Limiares (thresholds) são valores limite configuráveis para métricas, ao excedê-los o Firebase Performance gera um aviso. Os limiares são definidos no console do Firebase (Performance > Thresholds) para cada métrica automática: tempo de inicialização do aplicativo (frio/quente), tempo de renderização de tela, requisições HTTP lentas, tempo de resposta HTTP. Você pode definir limiares globais para todas as versões do aplicativo ou específicos para versões particulares.

Alertas (alerts) são notificações automáticas que o Firebase envia quando um limiar é excedido. Os alertas podem ser configurados por e-mail, webhook do Slack, PagerDuty ou Cloud Functions (para tratamento personalizado). Cada alerta contém: nome da métrica, valor atual, valor do limiar, versão do aplicativo, segmento (dispositivo, país). Os alertas permitem responder à degradação do desempenho antes que ela se torne perceptível aos usuários.

Limiares recomendados conforme o padrão da indústria (Google I/O 2025): inicialização a frio — menos de 2 segundos, inicialização a quente — menos de 1 segundo, renderização de tela — menos de 500 ms, duração de requisição HTTP — menos de 3000 ms (percentil 95), proporção de requisições lentas — menos de 5%. Para aplicativos altamente competitivos (Social, E-commerce), os limiares alvo podem ser mais rigorosos: inicialização a frio < 1.5 segundos, HTTP < 1000 ms.

Definindo limiares no console do Firebase

No console do Firebase, vá para a seção Performance, abra a aba Thresholds. Para cada métrica, defina o valor de limiar desejado e a porcentagem de usuários que deve ser afetada pela excedência. Por exemplo: "considerar inicialização a frio lenta se exceder 2 segundos para mais de 10% dos usuários". O Firebase mostrará os valores atuais das métricas e o histórico de excedências para ajudar a escolher limiares realistas.

Importante: os limiares não afetam a coleta de dados, eles apenas controlam a geração de notificações. Se o limiar for muito baixo (por exemplo, inicialização a frio 1 segundo, enquanto 50% dos dispositivos iniciam em 3 segundos), os alertas chegarão constantemente e se tornarão "ruído" que os desenvolvedores deixarão de notar. Defina limiares com base no desempenho atual, depois os ajuste gradualmente à medida que otimiza o aplicativo.

Painel de desempenho no console do Firebase

O painel de desempenho exibe as métricas-chave como séries temporais divididas por versão do aplicativo, dispositivo, país, tipo de conexão e versão do SO. Para cada métrica, estão disponíveis: média, mediana, percentil 95, percentil 99. O percentil 95 é a métrica mais informativa para avaliação de desempenho, pois mostra como o aplicativo funciona em dispositivos fracos, ignorando valores atípicos.

O painel suporta comparação de versões: selecione duas versões do aplicativo (atual e anterior) para comparação visual de métricas. Se após uma atualização o percentil 95 do tempo de inicialização aumentou de 2.1 para 3.4 segundos — a regressão é óbvia, e você precisa encontrar o commit que causou a lentidão. O Firebase Performance se integra com GitHub, GitLab e Bitbucket, permitindo vincular mudanças de métricas a commits específicos.

Exemplos de código para Performance Monitoring

Vejamos exemplos de integração do Firebase Performance Monitoring em um aplicativo Android com Kotlin. O código demonstra a criação de um rastreamento personalizado para medir o carregamento do feed de notícias, a adição de um atributo HTTP para uma requisição não interceptada automaticamente e o uso de Trace para medir o tempo de processamento de imagens. Todos os exemplos consideram a capacidade de desabilitar o rastreamento via Remote Config.

Antes de usar, adicione a dependência: implementation("com.google.firebase:firebase-perf") via Firebase BOM. Para instrumentação automática, nenhuma configuração adicional é necessária — o SDK intercepta as operações padrão automaticamente após adicionar a dependência.

Rastreamento personalizado para carregamento de feed

O primeiro exemplo — medição do tempo de carregamento do feed de notícias do servidor. O rastreamento envolve a operação assíncrona fetchFeed, que obtém dados da rede e analisa JSON. Atributos personalizados foram adicionados ao rastreamento: fonte de dados (cache ou network) e o número de posts recebidos. Isso permite segmentar os dados e entender em quais condições o feed carrega mais 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()
    }
}

A função loadFeedWithTrace recebe um parâmetro source ("cache" ou "network"), que é usado como atributo do rastreamento. Após a conclusão da operação assíncrona, o rastreamento para em um bloco finally, garantindo a parada mesmo em caso de exceção. A métrica items_count permite analisar como o número de posts afeta o tempo de carregamento. No console do Firebase, você pode filtrar os rastreamentos pelo atributo source e ver que o carregamento pela rede é 3 vezes mais lento que pelo cache.

Atributo HTTP para requisição não padrão

O segundo exemplo — atributo HTTP para uma requisição feita via WebSocket (não interceptada automaticamente). A classe HttpMetric é usada, permitindo registrar manualmente uma requisição URL, seu método, código de resposta e tamanho. O Firebase exibirá esta requisição na seção de Requisições de Rede junto com as interceptadas automaticamente.

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

No exemplo, sendWithHttpMetric usa newHttpMetric para registrar uma chamada HTTP não padrão. O SDK não a intercepta automaticamente, então o desenvolvedor define manualmente a URL, o método, o código de resposta e os tamanhos. É importante definir a URL sem parâmetros de consulta (por segurança e agregação) — isto é, /data, não /data?token=abc. O Firebase agrupa automaticamente padrões de URL idênticos.

Medição do tempo de processamento de imagem

O terceiro exemplo demonstra a medição do tempo de processamento de imagem (compressão, redimensionamento) usando um rastreamento personalizado. Neste caso, o rastreamento envolve uma operação síncrona, mas para produção use corrotinas ou RxJava para evitar bloquear a thread da 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
}

A função compressImage mede o tempo de compressão de imagem para JPEG com qualidade de 80%. O atributo format permite comparar o tempo de compressão JPEG versus WebP no futuro. A métrica output_size_kb mostra quão eficiente é a compressão. No console do Firebase, você pode ver a distribuição: em dispositivos fracos (Android de baixo custo), a compressão leva 4 vezes mais tempo do que em dispositivos topo de linha, o que pode ser a causa de atrasos ao enviar imagens para o servidor.

Como melhorar o desempenho baseado em dados

Firebase Performance fornece dados, mas não oferece soluções prontas. Analisar métricas requer entender as causas típicas de degradação de desempenho para cada métrica. Vamos ver os principais padrões de degradação e como diagnosticá-los usando os dados do Performance Monitoring. Abordagem: encontre uma anomalia em uma métrica → verifique as causas típicas → aplique a otimização → verifique o resultado após uma semana.

Inicialização a frio lenta (> 2 segundos): causas — inicialização pesada de SDK no Application.onCreate (analytics, relatórios de falha, SDK de mapas), carregamento de recursos grandes (fontes, temas), operações síncronas na thread principal na inicialização. Soluções: inicialização preguiçosa de SDK, carregamento adiado de recursos, uso da SplashScreen API (Android 12+) para mostrar um placeholder durante a inicialização. O Firebase Performance mostrará qual versão do aplicativo começou a ficar mais lenta — verifique quais dependências foram adicionadas ou atualizadas.

Renderização de tela lenta (> 500 ms): causas — hierarquia de View complexa (ConstraintLayout aninhado, múltiplos Fragment), carregamento de dados na thread da UI (rede ou disco), operações de desenho pesadas (imagens grandes, Views personalizadas). Soluções: otimizar a hierarquia de layout (Layout Inspector no Android Studio), descarregar dados para a thread de fundo, armazenar imagens em cache via Glide ou Coil. Use o filtro de Renderização de Tela no Firebase para encontrar a tela mais lenta e otimizá-la primeiro.

Otimizando requisições de rede

Requisições HTTP lentas (> 3 segundos): causas — servidor lento, payloads grandes, falta de cache, protocolo subótimo (HTTP/1.1 em vez de HTTP/2), resolução DNS. Soluções: verifique o lado do servidor (tempo de atividade, latência), reduza o tamanho da resposta (paginação, GraphQL, protobuf em vez de JSON), ative o cache via cabeçalhos HTTP (Cache-Control), use OkHttp Interceptor para adicionar tempos limite e lógica de repetição.

Firebase Performance mostra a distribuição do tempo da requisição: resolução DNS, handshake TCP, handshake TLS, envio da requisição, recebimento da resposta. Se a maior parte do tempo é gasta em DNS — use pré-carregamento de DNS (OkHttp DNS-over-HTTPS). Se em TLS — use retomada de sessão e ajuste de conjuntos de cifras. Se no recebimento da resposta — verifique o tamanho da resposta e a velocidade de rede do usuário. Os dados do Firebase permitem localizar o problema no nível do protocolo, em vez de apenas dizer "a requisição está lenta".

Integração Remote Config para desabilitar rastreamento

Para produção, recomenda-se adicionar uma flag Remote Config performance_tracing_enabled, que permite desabilitar remotamente os rastreamentos personalizados. Se o SDK do Firebase Performance no cliente gerar muitos dados ou afetar o desempenho (em dispositivos fracos), você pode desabilitar os rastreamentos para todos os usuários, deixando apenas as métricas automáticas, que têm overhead mínimo.

Exemplo de lógica: ao iniciar o aplicativo, verifique o parâmetro Remote Config performance_tracing_enabled. Se for false — todas as chamadas a Firebase.performance.newTrace() retornam um objeto stub que não coleta dados. Isso é implementado através de uma classe wrapper que verifica a flag antes de criar um rastreamento. Essa abordagem permite habilitar o rastreamento detalhado para usuários específicos (testadores beta, desenvolvedores) sem afetar todo o público.