Monitoraggio delle prestazioni — definizione, metriche e raccolta dati

Cos'è il monitoraggio delle prestazioni

Il monitoraggio delle prestazioni è la pratica di quantificare il comportamento dell'applicazione attraverso la raccolta di metriche di runtime, utilizzo della memoria, frame rate e consumo energetico. A differenza del crash reporting, che cattura solo i guasti fatali, il monitoraggio delle prestazioni traccia il degrado graduale: l'app funziona ma è più lenta del dovuto.

Secondo Google (2024), il 53% degli utenti chiude un'app se impiega più di 3 secondi per caricarsi. Ogni secondo aggiuntivo di ritardo riduce la conversione del 20% in media tra le categorie. Questo rende il monitoraggio delle prestazioni non solo una pratica tecnica ma una necessità aziendale per i prodotti mobili.

Il monitoraggio moderno delle prestazioni copre quattro livelli: lato client (iOS, Android), rete (richieste API, WebSocket), servizi backend e infrastruttura. Nello sviluppo mobile, l'attenzione è sulle metriche lato client, poiché la maggior parte dei problemi di prestazione si verifica sul dispositivo dell'utente.

Metriche chiave di un'app mobile

Per un monitoraggio completo, è necessario tracciare cinque gruppi di metriche, ciascuno responsabile di un diverso aspetto dell'esperienza utente. FPS (fotogrammi al secondo) mostra la fluidità di animazioni e scorrimento: valori inferiori a 30 fotogrammi al secondo vengono percepiti come rallentamento.

Metriche temporali

Tempo di avvio a freddo — dal momento in cui si tocca l'icona fino alla completa prontezza dell'interfaccia. Tempo di avvio a caldo — ritorno dallo sfondo. Tempo di risposta all'azione dell'utente (tap-to-response). Il tempo di avvio per Android viene misurato tramite ActivityManager, per iOS — tramite dyld e tempo premain. Secondo Firebase Performance, il tempo mediano di avvio a freddo per le prime 100 app è di 1,8 secondi.

Metriche di memoria e CPU

Il consumo di RAM non deve superare l'80% della capacità disponibile sul dispositivo, altrimenti il sistema inizia a scaricare l'app dallo sfondo. L'impronta di memoria viene tracciata tramite Xcode Instruments (iOS) e Android Profiler. Le perdite di memoria vengono rilevate dall'aumento del consumo durante operazioni ripetute — ad esempio, passando da uno schermo all'altro.

Metriche di rete

Tempo di esecuzione della richiesta HTTP, dimensione della risposta, frequenza di timeout ed errori. La latenza di rete è particolarmente critica per le app mobili che operano in condizioni di connessione instabili (3G, metropolitana, ascensore, roaming). Si consiglia di tracciare il tempo di risposta p95 — mostra l'esperienza degli utenti più “pesanti” con le peggiori condizioni di rete.

Real User Monitoring e Synthetic Monitoring

Real User Monitoring (RUM) raccoglie dati dai dispositivi reali degli utenti nell'ambiente di produzione. Questo metodo mostra le latenze effettive che gli utenti sperimentano considerando i loro dispositivi, versioni del sistema operativo, rete e geolocalizzazione. Il RUM fornisce l'immagine più accurata delle prestazioni ma dipende da quali utenti sono nel campione.

Synthetic Monitoring, d'altra parte, esegue scenari predefiniti su dispositivi di test in condizioni controllate. Consente di rilevare le regressioni prima che raggiungano gli utenti e di riprodurre i problemi in un ambiente coerente. Firebase Test Lab e BrowserStack forniscono test sintetici su dispositivi reali senza esecuzione manuale.

La strategia ottimale è una combinazione di entrambi gli approcci: i test sintetici catturano le regressioni nella fase CI, mentre il RUM fornisce l'immagine reale in produzione. Secondo Datadog (2024), i team che utilizzano entrambi i metodi scoprono il 35% in più di problemi di prestazione prima che diventino incidenti.

Configurazione di Firebase Performance Monitoring

Firebase Performance Monitoring è uno strumento gratuito di Google per la raccolta di metriche delle prestazioni su iOS e Android. Misura automaticamente il tempo di avvio dell'app, le richieste HTTP e il rendering degli schermi senza scrivere codice. Per configurarlo, basta aggiungere l'SDK al progetto e attivare il modulo Performance nella console Firebase.

Raccolta automatica delle metriche

Dopo aver integrato l'SDK, Firebase Performance crea automaticamente un trace per ogni richiesta HTTP tramite URLSession (iOS) o OkHttp (Android). Il rendering dello schermo viene misurato per UIViewController e Activity, catturando il tempo da onCreate/viewDidLoad al completamento del primo rendering. Tutte le metriche sono aggregate nella console Firebase, suddivise per versione dell'app, dispositivo e paese.

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

class PaymentService {
    private val firebasePerf = FirebasePerformance.getInstance()

    fun processPayment(amount: Double) {
        val trace = firebasePerf.newTrace("payment-flow")
        trace.start()
        trace.putAttribute("amount", amount.toString())
        // esecuzione del pagamento
        trace.stop()
    }
}

Il codice crea un trace personalizzato per lo scenario di pagamento con un attributo di importo. Utilizzando questo trace nella console Firebase, è possibile vedere il tempo di esecuzione medio e p95 del pagamento, raggruppato per versione dell'app e dispositivo.

Monitoraggio HTTP

Firebase intercetta automaticamente le richieste di rete e registra URL, codice di risposta, dimensione del payload e tempo di esecuzione. Per OkHttp su Android, l'instrumentazione automatica funziona senza configurazione aggiuntiva. Le richieste di rete vengono visualizzate nella console raggruppate per endpoint, consentendo di identificare rapidamente il rallentamento di un'API specifica.

Trace personalizzati per la logica di business

Le metriche standard coprono le prestazioni generali, ma per diagnosticare i processi aziendali è necessario instrumentare scenari specifici. I trace personalizzati consentono di misurare il tempo di esecuzione di autenticazione, caricamento del feed di notizie, elaborazione delle immagini o sincronizzazione dei dati.

Ogni trace personalizzato dovrebbe avere un nome significativo nel formato “scenario-azione” e contenere attributi per il filtraggio. Ad esempio, un trace “image-upload” con attributi “file_size” e “compression_quality” aiuterà a identificare la dipendenza del tempo di upload dalla dimensione dell'immagine. Si consiglia di non creare più di 20 trace personalizzati per schermo — un'instrumentazione eccessiva crea rumore e complica l'analisi.

import FirebasePerformance

func trackImageUpload(data: Data) {
    let trace = Performance.startTrace(name: "image-upload")
    trace?.setValue(data.count, forAttribute: "file_size")
    trace?.setValue("high", forAttribute: "compression")
    // caricamento immagine
    trace?.stop()
}

L'esempio in Swift crea un trace per il caricamento delle immagini con attributi di dimensione del file e livello di compressione. Nella console Firebase, questi attributi diventano campi per raggruppare e filtrare le metriche.

Soglie e avvisi

Raccogliere metriche senza un sistema di avvisi è inutile. Gli avvisi dovrebbero notificare al team quando le metriche superano i limiti accettabili, con soglie divise in tre livelli: avviso, critico e interruzione. Ogni livello determina il canale di notifica: avviso — sul canale Slack del team, critico — su PagerDuty per l'ingegnere di turno, interruzione — notifica di massa a tutti gli stakeholder.

Per le metriche mobili, si consiglia di utilizzare soglie dinamiche basate su percentili: il tempo di avvio a freddo p95 supera i 4 secondi — avviso critico. Le soglie statiche (ad esempio, CPU > 90%) funzionano peggio perché non tengono conto delle normali fluttuazioni del carico in base all'ora del giorno e al giorno della settimana. Firebase Performance supporta la configurazione di avvisi tramite Firebase Console con notifiche a Slack, PagerDuty ed email, con opzioni di escalation in caso di mancata conferma.

Secondo il Sondaggio sulla Gestione degli Incidenti (2024), i team che impostano avvisi basati su percentili anziché medie perdono il 45% in meno di incidenti. Il valore medio appiattisce i valori anomali — il p95 garantisce di mostrare lo scenario peggiore per gli utenti, indipendentemente dall'ora del giorno e dalle fluttuazioni stagionali del carico.