Firebase Performance: cos’è, metriche e come tracciare

Cos’è Firebase Performance Monitoring

Firebase Performance Monitoring è un SDK e una piattaforma cloud per raccogliere, aggregare e visualizzare le metriche delle prestazioni delle app mobili. L’SDK viene integrato nell’app e strumenta automaticamente i punti chiave: il ciclo di vita dell’Activity (Android) o del ViewController (iOS), le richieste di rete tramite URLSession (iOS) o OkHttp (Android) e le chiamate di sistema. I dati raccolti vengono inviati al server Firebase, dove vengono aggregati per versione dell’app, dispositivo, paese e altri attributi.

L’architettura dell’SDK Performance si basa sul principio del sovraccarico minimo: la strumentazione aggiunge non più dell’1–2% al tempo di esecuzione delle operazioni misurate. I dati vengono raccolti in modo asincrono e bufferizzati sul dispositivo prima dell’invio, eliminando qualsiasi impatto sulle prestazioni del thread UI. I dati vengono inviati secondo una pianificazione (per impostazione predefinita ogni 30 minuti) o quando il buffer raggiunge 100 KB.

La differenza principale tra Firebase Performance e i profiler di Android Studio (CPU Profiler) o Xcode Instruments è il monitoraggio in produzione. Firebase Performance raccoglie dati da dispositivi reali degli utenti, non solo da dispositivi di sviluppo. Ciò consente di rilevare problemi che si verificano solo su modelli specifici, versioni del sistema operativo o in regioni particolari — problemi che non possono essere riprodotti in un ambiente controllato.

Come l’SDK raccoglie dati senza modifiche al codice

La strumentazione automatica è la caratteristica principale di Firebase Performance. Per Android, l’SDK registra automaticamente ActivityLifecycleCallbacks e misura il tempo tra onCreate e onResume (tempo di rendering dello schermo). Per iOS, effettua lo swizzle dei metodi viewDidLoad e viewDidAppear. Le richieste di rete vengono intercettate a livello di OkHttpInterceptor (Android) o NSURLProtocol (iOS). Lo sviluppatore non deve aggiungere chiamate start/stop per le metriche standard.

Abilitazione e disabilitazione dell’SDK Performance viene gestita tramite il plugin Google Services (Android) o Info.plist (iOS). Per il debug, è possibile abilitare la registrazione dettagliata dell’SDK Performance, che mostra quali metriche vengono raccolte e inviate. In produzione, si consiglia di mantenere la registrazione a livello di avviso per evitare di ingombrare i log con informazioni non necessarie. Per i progetti su Flutter o React Native, la strumentazione automatica potrebbe essere limitata — maggiori dettagli nella sezione degli esempi di codice.

Limiti gratuiti e prezzi

Firebase Performance è disponibile sul piano gratuito Spark senza limiti sul numero di tracce o sul volume di dati. Anche il piano a pagamento Blaze non addebita costi per Performance Monitoring — è uno dei pochi servizi Firebase completamente gratuiti su entrambi i piani. C’è solo una limitazione: i dati vengono conservati per 30 giorni (su Spark) e fino a 365 giorni (su Blaze). Per l’analisi a lungo termine, esporta i dati tramite BigQuery export.

Gratuito rende Firebase Performance la scelta ideale per qualsiasi progetto — dal prototipo all’applicazione aziendale con milioni di utenti. L’unica spesa è il traffico in uscita dell’SDK Performance, ma è trascurabile rispetto ad altre operazioni di rete dell’app (meno di 1 MB al mese per dispositivo). BigQuery export addebita costi per archiviazione e query, ma l’SDK Performance stesso è gratuito.

Metriche automatiche: cosa viene misurato senza codice

Firebase Performance raccoglie automaticamente cinque categorie di metriche senza una singola riga di codice: tempo di avvio dell’app, richieste HTTP lente, velocità di rendering degli schermi, utilizzo della memoria (solo Android) e frequenza dei fotogrammi (solo Android). Queste metriche sono disponibili nella console Firebase immediatamente dopo aver collegato l’SDK e la prima sessione utente.

Tempo di avvio dell’app — il tempo dall’avvio del processo fino alla piena prontezza dell’interfaccia utente per l’interazione. Si suddivide in avvio a freddo (l’app parte da zero) e avvio a caldo (l’app riprende dallo stato in background). L’avvio a freddo include il caricamento dei file DEX, l’inizializzazione dei campi statici, la chiamata a Application.onCreate e Activity.onCreate. Firebase classifica automaticamente il tipo di avvio e mostra la distribuzione temporale per ciascun tipo.

Tempo di rendering dello schermo — il tempo dall’inizio del caricamento dello schermo (onCreate per Android, viewDidLoad per iOS) fino al momento in cui lo schermo è pronto per l’interazione (onResume, viewDidAppear). Firebase aggrega i dati per ogni schermo (per nome della classe o nome dello schermo personalizzato), consentendo di identificare quale schermo impiega più tempo a caricarsi. Per Android, vengono misurati anche i fotogrammi persi — il numero di fotogrammi saltati durante il rendering dello schermo (jank).

Richieste di rete (HTTP/HTTPS)

L’SDK Performance intercetta e misura automaticamente ogni richiesta HTTP/HTTPS inviata dall’app tramite URLSession, OkHttp o URLConnection. Per ogni richiesta vengono registrati: URL (percorso senza parametri di query per sicurezza), metodo HTTP, codice di risposta, dimensione della risposta in byte, durata della richiesta e velocità di connessione (WiFi, Cellulare). I dati vengono aggregati nel dashboard Richieste di rete della console Firebase.

Richieste lente — richieste la cui durata supera una soglia impostata. Per impostazione predefinita, la soglia per le richieste lente è di 4000 ms. Questa metrica è fondamentale per identificare i problemi del backend: se dopo un aggiornamento del backend, il numero di richieste lente passa dall’1% al 15%, è un segnale per un’analisi immediata dei log del server. Gli utenti non aspetteranno più di 5 secondi per una risposta — i dati Firebase mostrano che il 53% degli utenti chiude l’app se una richiesta impiega più di 3 secondi.

Limitazioni della strumentazione automatica

Limitazioni iOS: su iOS, l’SDK Performance non può misurare i fotogrammi persi (questa è un’API privata). Per misurare il jank su iOS, utilizza MetricKit o CADisplayLink. Inoltre, su iOS, l’SDK non intercetta le richieste effettuate tramite client HTTP di terze parti che non utilizzano URLSession (ad esempio SwiftNIO). Per questi casi, utilizza tracce personalizzate con attributi HTTP.

Limitazioni Android: su Android, la misurazione automatica della memoria è disponibile solo su dispositivi con Android 8.0+ (API 26+). Per le versioni precedenti, utilizza tracce personalizzate con dati ottenuti tramite Debug.getMemoryInfo(). Inoltre, l’SDK non intercetta le connessioni WebSocket — richiedono tracce separate. Nonostante queste limitazioni, le metriche automatiche coprono l’80% delle esigenze di monitoraggio delle prestazioni.

Tracce personalizzate e attributi HTTP

Le tracce personalizzate sono intervalli di tempo denominati che lo sviluppatore crea manualmente per misurare le prestazioni di scenari specifici: caricare un feed di notizie, elaborare un’immagine, sincronizzare dati, eseguire una query complessa al database. Le tracce personalizzate completano le metriche automatiche e consentono di misurare esattamente i segmenti di codice che lo sviluppatore considera critici per le prestazioni.

Ogni traccia ha un nome (massimo 100 caratteri) e può contenere fino a 5 metriche personalizzate — valori numerici registrati all’interno della traccia. Ad esempio, in una traccia “image_processing”, puoi misurare metriche come “original_file_size” e “processed_file_size”. Le metriche vengono visualizzate nella console Firebase come distribuzioni (min, max, media, percentili), consentendo di analizzare non solo la durata ma anche le caratteristiche dell’operazione.

Attributi HTTP — un tipo speciale di traccia personalizzata per richieste di rete che non sono state intercettate automaticamente dall’SDK (ad esempio tramite WebSocket o librerie di terze parti). Gli attributi HTTP includono URL, metodo HTTP, codice di risposta e dimensione della risposta. Firebase li mostra nella sezione Richieste di rete insieme alle richieste raccolte automaticamente, fornendo un quadro unificato dell’interazione di rete.

Quando utilizzare le tracce personalizzate

Le tracce personalizzate sono indispensabili per misurare: tempo di caricamento dei dati dal database locale (Room, CoreData), durata di calcoli complessi (crittografia, compressione), prestazioni di animazioni e transizioni, tempo di risposta di SDK di terze parti (mappe, pagamenti, analisi). Per ciascuno di questi scenari, crea una traccia, avvolgi il codice misurato in start/stop e aggiungi attributi per la successiva segmentazione.

Non abusare delle tracce personalizzate. Ogni traccia aggiunge un consumo aggiuntivo di batteria e traffico. Si consiglia di non avere più di 10–15 tracce attive nella versione di produzione dell’app. Per il debug, puoi aggiungere più tracce, ma prima del rilascio, disabilita quelle eccessive tramite Remote Config (usa il flag performance_tracing_enabled). Ciò consente di attivare la tracciatura dettagliata solo per utenti o sessioni selezionati.

Attributi delle tracce per la segmentazione

Gli attributi personalizzati sono coppie chiave-valore che possono essere aggiunte a una traccia per un successivo filtraggio nella console Firebase. Ad esempio, per la traccia “feed_load”, puoi aggiungere attributi come “feed_type” (main, explore, following) e “cache_status” (cold, warm). Nella console, i dati della traccia possono essere filtrati per questi attributi per determinare quale tipo di feed si carica più lentamente.

Limitazioni: ogni traccia può avere fino a 5 attributi personalizzati. I valori degli attributi sono stringhe fino a 100 caratteri. Gli attributi devono essere impostati prima dell’inizio della traccia; la modifica di un attributo dopo l’inizio viene ignorata. Questa limitazione è legata alle prestazioni: fissare gli attributi dopo l’inizio richiederebbe una sincronizzazione aggiuntiva.

Soglie di prestazione e avvisi

Le soglie sono valori limite configurabili per le metriche, al superamento dei quali Firebase Performance genera un avviso. Le soglie vengono impostate nella console Firebase (Performance > Thresholds) per ogni metrica automatica: tempo di avvio dell’app (freddo/caldo), tempo di rendering dello schermo, richieste HTTP lente, tempo di risposta HTTP. Puoi impostare soglie globali per tutte le versioni dell’app o specifiche per versioni particolari.

Gli avvisi sono notifiche automatiche che Firebase invia quando una soglia viene superata. Gli avvisi possono essere configurati tramite email, webhook Slack, PagerDuty o Cloud Functions (per elaborazione personalizzata). Ogni avviso contiene: nome della metrica, valore corrente, valore soglia, versione dell’app, segmento (dispositivo, paese). Gli avvisi consentono di reagire al degrado delle prestazioni prima che diventi evidente per gli utenti.

Soglie raccomandate secondo lo standard industriale (Google I/O 2025): avvio a freddo — meno di 2 secondi, avvio a caldo — meno di 1 secondo, rendering dello schermo — meno di 500 ms, durata della richiesta HTTP — meno di 3000 ms (95° percentile), proporzione di richieste lente — meno del 5%. Per app altamente competitive (Social, E-commerce), le soglie target possono essere più rigorose: avvio a freddo < 1,5 secondi, HTTP < 1000 ms.

Impostazione delle soglie nella console Firebase

Nella console Firebase, vai alla sezione Performance, apri la scheda Thresholds. Per ogni metrica, imposta il valore soglia desiderato e la percentuale di utenti che dovrebbe essere interessata dal superamento. Ad esempio: “considerare l’avvio a freddo lento se supera i 2 secondi per più del 10% degli utenti”. Firebase mostrerà i valori correnti delle metriche e la cronologia dei superamenti per aiutarti a scegliere soglie realistiche.

Importante: le soglie non influenzano la raccolta dei dati, controllano solo la generazione di notifiche. Se la soglia è troppo bassa (ad esempio, avvio a freddo 1 secondo, mentre il 50% dei dispositivi si avvia in 3 secondi), gli avvisi arriveranno costantemente e diventeranno “rumore” che gli sviluppatori smetteranno di notare. Imposta le soglie in base alle prestazioni correnti, poi stringile gradualmente man mano che ottimizzi l’app.

Dashboard delle prestazioni nella console Firebase

Il dashboard delle prestazioni mostra le metriche chiave come serie temporali suddivise per versione dell’app, dispositivo, paese, tipo di connessione e versione del sistema operativo. Per ogni metrica, sono disponibili: media, mediana, 95° percentile, 99° percentile. Il 95° percentile è la metrica più informativa per la valutazione delle prestazioni, poiché mostra come l’app funziona sui dispositivi deboli, ignorando i valori anomali.

Il dashboard supporta il confronto tra versioni: seleziona due versioni dell’app (corrente e precedente) per il confronto visivo delle metriche. Se dopo un aggiornamento il 95° percentile del tempo di avvio aumenta da 2,1 a 3,4 secondi — la regressione è evidente e devi trovare il commit che ha causato il rallentamento. Firebase Performance si integra con GitHub, GitLab e Bitbucket, consentendo di collegare le modifiche delle metriche a commit specifici.

Esempi di codice per Performance Monitoring

Vediamo esempi di integrazione di Firebase Performance Monitoring in un’app Android con Kotlin. Il codice dimostra la creazione di una traccia personalizzata per misurare il caricamento del feed di notizie, l’aggiunta di un attributo HTTP per una richiesta non intercettata automaticamente e l’utilizzo di Trace per misurare il tempo di elaborazione delle immagini. Tutti gli esempi tengono conto della possibilità di disabilitare la tracciatura tramite Remote Config.

Prima dell’uso, aggiungi la dipendenza: implementation("com.google.firebase:firebase-perf") tramite Firebase BOM. Per la strumentazione automatica, non è necessaria alcuna configurazione aggiuntiva — l’SDK intercetta automaticamente le operazioni standard dopo l’aggiunta della dipendenza.

Traccia personalizzata per il caricamento del feed

Il primo esempio — misurazione del tempo di caricamento del feed di notizie dal server. La traccia avvolge l’operazione asincrona fetchFeed, che recupera i dati dalla rete e analizza JSON. Sono stati aggiunti attributi personalizzati alla traccia: fonte dei dati (cache o rete) e numero di post ricevuti. Ciò consente di segmentare i dati e capire in quali condizioni il feed si carica più 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 funzione loadFeedWithTrace accetta un parametro source (“cache” o “network”), che viene utilizzato come attributo della traccia. Dopo il completamento dell’operazione asincrona, la traccia si ferma in un blocco finally, garantendo l’arresto anche in caso di eccezione. La metrica items_count consente di analizzare come il numero di post influisce sul tempo di caricamento. Nella console Firebase, puoi filtrare le tracce per l’attributo source e vedere che il caricamento dalla rete è 3 volte più lento che dalla cache.

Attributo HTTP per richiesta non standard

Il secondo esempio — attributo HTTP per una richiesta effettuata tramite WebSocket (non intercettata automaticamente). Viene utilizzata la classe HttpMetric, che consente di registrare manualmente una richiesta URL, il suo metodo, il codice di risposta e la dimensione. Firebase mostrerà questa richiesta nella sezione Richieste di rete insieme alle richieste intercettate 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()
    }
}

Nell’esempio, sendWithHttpMetric utilizza newHttpMetric per registrare una chiamata HTTP non standard. L’SDK non la intercetta automaticamente, quindi lo sviluppatore imposta manualmente URL, metodo, codice di risposta e dimensioni. È importante impostare l’URL senza parametri di query (per sicurezza e aggregazione) — cioè /data, non /data?token=abc. Firebase raggruppa automaticamente i modelli URL identici.

Misurazione del tempo di elaborazione delle immagini

Il terzo esempio dimostra la misurazione del tempo di elaborazione delle immagini (compressione, ridimensionamento) utilizzando una traccia personalizzata. In questo caso, la traccia avvolge un’operazione sincrona, ma per la produzione utilizza coroutine o RxJava per evitare di bloccare il thread 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 funzione compressImage misura il tempo di compressione dell’immagine in JPEG con qualità dell’80%. L’attributo format consente di confrontare in futuro il tempo di compressione JPEG rispetto a WebP. La metrica output_size_kb mostra l’efficienza della compressione. Nella console Firebase, puoi vedere la distribuzione: sui dispositivi deboli (Android economici), la compressione richiede 4 volte più tempo rispetto ai dispositivi di punta, il che potrebbe essere la causa di ritardi nel caricamento delle immagini sul server.

Come migliorare le prestazioni basandosi sui dati

Firebase Performance fornisce dati ma non offre soluzioni pronte. L’analisi delle metriche richiede di comprendere le cause tipiche del degrado delle prestazioni per ciascuna metrica. Vediamo i principali modelli di degrado e come diagnosticarli utilizzando i dati di Performance Monitoring. Approccio: trova un’anomalia in una metrica → verifica le cause tipiche → applica l’ottimizzazione → verifica il risultato dopo una settimana.

Avvio a freddo lento (> 2 secondi): cause — inizializzazione pesante dell’SDK in Application.onCreate (analisi, crash reporting, SDK mappe), caricamento di risorse grandi (font, temi), operazioni sincrone sul thread principale all’avvio. Soluzioni: inizializzazione lazy dell’SDK, caricamento differito delle risorse, utilizzo dell’API SplashScreen (Android 12+) per mostrare un placeholder durante l’inizializzazione. Firebase Performance mostrerà quale versione dell’app ha iniziato a rallentare — verifica quali dipendenze sono state aggiunte o aggiornate.

Rendering dello schermo lento (> 500 ms): cause — gerarchia di View complessa (ConstraintLayout annidato, molteplici Fragment), caricamento dei dati nel thread UI (rete o disco), operazioni di disegno pesanti (immagini grandi, View personalizzate). Soluzioni: ottimizzare la gerarchia del layout (Layout Inspector in Android Studio), scaricare i dati nel thread in background, mettere in cache le immagini tramite Glide o Coil. Utilizza il filtro Rendering dello schermo in Firebase per trovare lo schermo più lento e ottimizzarlo per primo.

Ottimizzazione delle richieste di rete

Richieste HTTP lente (> 3 secondi): cause — server lento, payload grandi, mancanza di caching, protocollo non ottimale (HTTP/1.1 invece di HTTP/2), risoluzione DNS. Soluzioni: verifica il lato server (uptime, latenza), riduci la dimensione della risposta (paginazione, GraphQL, protobuf invece di JSON), attiva la cache tramite intestazioni HTTP (Cache-Control), utilizza OkHttp Interceptor per aggiungere timeout e logica di ripetizione.

Firebase Performance mostra la distribuzione temporale della richiesta: risoluzione DNS, handshake TCP, handshake TLS, invio richiesta, ricezione risposta. Se la maggior parte del tempo viene spesa per il DNS — utilizza il precaricamento DNS (OkHttp DNS-over-HTTPS). Se per TLS — utilizza la ripresa della sessione e la regolazione delle suite di cifratura. Se per la ricezione della risposta — verifica la dimensione della risposta e la velocità della rete dell’utente. I dati Firebase consentono di localizzare il problema a livello di protocollo, invece di dire semplicemente “la richiesta è lenta”.

Integrazione Remote Config per disabilitare la tracciatura

Per la produzione, si consiglia di aggiungere un flag Remote Config performance_tracing_enabled, che consente di disabilitare da remoto le tracce personalizzate. Se l’SDK Firebase Performance sul client genera troppi dati o influisce sulle prestazioni (sui dispositivi deboli), puoi disabilitare le tracce per tutti gli utenti, lasciando solo le metriche automatiche, che hanno un sovraccarico minimo.

Esempio di logica: all’avvio dell’app, verifica il parametro Remote Config performance_tracing_enabled. Se false — tutte le chiamate a Firebase.performance.newTrace() restituiscono un oggetto stub che non raccoglie dati. Ciò viene implementato tramite una classe wrapper che verifica il flag prima di creare una traccia. Questo approccio consente di attivare la tracciatura dettagliata per utenti specifici (beta tester, sviluppatori) senza influenzare l’intero pubblico.