Firebase Performance : ce que c’est, les métriques et comment les suivre

Qu’est-ce que Firebase Performance Monitoring

Firebase Performance Monitoring est un SDK et une plateforme cloud pour collecter, agréger et visualiser les métriques de performance des applications mobiles. Le SDK est intégré dans l’application et instrumente automatiquement les points clés : le cycle de vie de l’Activity (Android) ou du ViewController (iOS), les requêtes réseau via URLSession (iOS) ou OkHttp (Android), et les appels système. Les données collectées sont envoyées au serveur Firebase, où elles sont agrégées par version d’application, appareil, pays et d’autres attributs.

L’architecture du SDK Performance est basée sur le principe d’impact minimal : l’instrumentation n’ajoute pas plus de 1–2 % au temps d’exécution des opérations mesurées. Les données sont collectées de manière asynchrone et mises en mémoire tampon sur l’appareil avant l’envoi, éliminant ainsi tout impact sur les performances du thread UI. Les données sont envoyées selon un calendrier (par défaut toutes les 30 minutes) ou lorsque le tampon atteint 100 Ko.

La principale différence entre Firebase Performance et les profileurs d’Android Studio (CPU Profiler) ou Xcode Instruments est la surveillance en production. Firebase Performance collecte des données à partir d’appareils réels d’utilisateurs, pas seulement d’appareils de développeurs. Cela permet de détecter des problèmes qui ne se produisent que sur certains modèles, versions d’OS ou régions particulières — des problèmes impossibles à reproduire dans un environnement contrôlé.

Comment le SDK collecte les données sans modification de code

L’instrumentation automatique est la principale fonctionnalité de Firebase Performance. Pour Android, le SDK enregistre automatiquement ActivityLifecycleCallbacks et mesure le temps entre onCreate et onResume (temps de rendu de l’écran). Pour iOS, il swizzle les méthodes viewDidLoad et viewDidAppear. Les requêtes réseau sont interceptées au niveau OkHttpInterceptor (Android) ou NSURLProtocol (iOS). Le développeur n’a pas besoin d’ajouter d’appels start/stop pour les métriques standard.

L’activation et la désactivation du SDK Performance sont gérées via le plugin Google Services (Android) ou Info.plist (iOS). Pour le débogage, vous pouvez activer la journalisation détaillée du SDK Performance, qui montre quelles métriques sont collectées et envoyées. En production, il est recommandé de conserver la journalisation au niveau d’avertissement pour éviter d’encombrer les journaux avec des informations inutiles. Pour les projets sur Flutter ou React Native, l’instrumentation automatique peut être limitée ; plus de détails dans la section des exemples de code.

Limites gratuites et tarification

Firebase Performance est disponible sur le niveau gratuit Spark sans limite du nombre de traces ou du volume de données. Le niveau payant Blaze ne facture pas non plus le Performance Monitoring — c’est l’un des rares services Firebase entièrement gratuits sur les deux niveaux. Il n’y a qu’une seule limitation : les données sont conservées pendant 30 jours (sur Spark) et jusqu’à 365 jours (sur Blaze). Pour une analyse à long terme, exportez les données via BigQuery export.

Gratuit fait de Firebase Performance un choix idéal pour tout projet — du prototype à l’application d’entreprise avec des millions d’utilisateurs. La seule dépense est le trafic sortant du SDK Performance, mais il est négligeable par rapport aux autres opérations réseau de l’application (moins de 1 Mo par mois par appareil). BigQuery export facture le stockage et les requêtes, mais le SDK Performance lui-même est gratuit.

Métriques automatiques : ce qui est mesuré sans code

Firebase Performance collecte automatiquement cinq catégories de métriques sans une seule ligne de code : temps de démarrage de l’application, requêtes HTTP lentes, vitesse de rendu des écrans, utilisation de la mémoire (Android uniquement) et fréquence d’images (Android uniquement). Ces métriques sont disponibles dans la console Firebase immédiatement après la connexion du SDK et la première session utilisateur.

Temps de démarrage de l’application — le temps depuis le démarrage du processus jusqu’à ce que l’interface utilisateur soit entièrement prête pour l’interaction. Il est divisé en démarrage à froid (l’application démarre à partir de zéro) et démarrage à chaud (l’application reprend depuis l’arrière-plan). Le démarrage à froid comprend le chargement des fichiers DEX, l’initialisation des champs statiques, l’appel à Application.onCreate et Activity.onCreate. Firebase classifie automatiquement le type de démarrage et affiche la distribution temporelle pour chaque type.

Temps de rendu d’écran — le temps depuis le début du chargement de l’écran (onCreate pour Android, viewDidLoad pour iOS) jusqu’au moment où l’écran est prêt pour l’interaction (onResume, viewDidAppear). Firebase agrège les données par écran (par nom de classe ou nom d’écran personnalisé), permettant d’identifier quel écran charge le plus longtemps. Pour Android, les images perdues sont également mesurées — le nombre d’images ignorées lors du rendu de l’écran (jank).

Requêtes réseau (HTTP/HTTPS)

Le SDK Performance intercepte et mesure automatiquement chaque requête HTTP/HTTPS envoyée par l’application via URLSession, OkHttp ou URLConnection. Pour chaque requête, sont enregistrés : URL (chemin sans paramètres de requête pour la sécurité), méthode HTTP, code de réponse, taille de la réponse en octets, durée de la requête et vitesse de connexion (WiFi, Cellulaire). Les données sont agrégées dans le tableau de bord Requêtes réseau de la console Firebase.

Requêtes lentes — requêtes dont la durée dépasse un seuil défini. Par défaut, le seuil de requête lente est de 4000 ms. Cette métrique est essentielle pour identifier les problèmes de backend : si après une mise à jour du backend, le nombre de requêtes lentes passe de 1 % à 15 %, c’est un signal pour une analyse immédiate des journaux du serveur. Les utilisateurs n’attendront pas plus de 5 secondes pour une réponse — les données Firebase montrent que 53 % des utilisateurs ferment l’application si une requête prend plus de 3 secondes.

Limitations de l’instrumentation automatique

Limitations iOS : sur iOS, le SDK Performance ne peut pas mesurer les images perdues (c’est une API privée). Pour mesurer le jank sur iOS, utilisez MetricKit ou CADisplayLink. De plus, sur iOS, le SDK n’intercepte pas les requêtes effectuées via des clients HTTP tiers qui n’utilisent pas URLSession (par exemple, SwiftNIO). Pour ces cas, utilisez des traces personnalisées avec des attributs HTTP.

Limitations Android : sur Android, la mesure automatique de la mémoire n’est disponible que sur les appareils avec Android 8.0+ (API 26+). Pour les versions antérieures, utilisez des traces personnalisées avec des données obtenues via Debug.getMemoryInfo(). De plus, le SDK n’intercepte pas les connexions WebSocket — elles nécessitent des traces séparées. Malgré ces limitations, les métriques automatiques couvrent 80 % des besoins de surveillance des performances.

Traces personnalisées et attributs HTTP

Les traces personnalisées sont des intervalles de temps nommés que le développeur crée manuellement pour mesurer les performances de scénarios spécifiques : charger un fil d’actualité, traiter une image, synchroniser des données, exécuter une requête complexe de base de données. Les traces personnalisées complètent les métriques automatiques et permettent de mesurer exactement les segments de code que le développeur considère comme critiques pour les performances.

Chaque trace a un nom (maximum 100 caractères) et peut contenir jusqu’à 5 métriques personnalisées — des valeurs numériques enregistrées dans la trace. Par exemple, dans une trace « image_processing », vous pouvez mesurer des métriques comme « original_file_size » et « processed_file_size ». Les métriques sont affichées dans la console Firebase sous forme de distributions (min, max, moyenne, percentiles), permettant d’analyser non seulement la durée mais aussi les caractéristiques de l’opération.

Attributs HTTP — un type spécial de trace personnalisée pour les requêtes réseau qui n’ont pas été interceptées automatiquement par le SDK (par exemple, via WebSocket ou des bibliothèques tierces). Les attributs HTTP incluent l’URL, la méthode HTTP, le code de réponse et la taille de la réponse. Firebase les affiche dans la section Requêtes réseau avec les requêtes collectées automatiquement, offrant une image unifiée de l’interaction réseau.

Quand utiliser les traces personnalisées

Les traces personnalisées sont indispensables pour mesurer : le temps de chargement des données depuis une base de données locale (Room, CoreData), la durée de calculs complexes (cryptage, compression), les performances des animations et transitions, le temps de réponse des SDK tiers (cartes, paiements, analyses). Pour chacun de ces scénarios, créez une trace, encapsulez le code mesuré dans start/stop et ajoutez des attributs pour la segmentation ultérieure.

N’abusez pas des traces personnalisées. Chaque trace ajoute une consommation supplémentaire de batterie et de trafic. Il est recommandé de ne pas avoir plus de 10–15 traces actives dans la version de production de l’application. Pour le débogage, vous pouvez ajouter plus de traces, mais avant la publication, désactivez les traces excessives via Remote Config (utilisez le drapeau performance_tracing_enabled). Cela permet d’activer le traçage détaillé uniquement pour certains utilisateurs ou sessions.

Attributs de trace pour la segmentation

Les attributs personnalisés sont des paires clé-valeur qui peuvent être ajoutées à une trace pour un filtrage ultérieur dans la console Firebase. Par exemple, pour la trace « feed_load », vous pouvez ajouter des attributs comme « feed_type » (main, explore, following) et « cache_status » (cold, warm). Dans la console, les données de trace peuvent être filtrées par ces attributs pour déterminer quel type de fil charge le plus lentement.

Limitations : chaque trace peut avoir jusqu’à 5 attributs personnalisés. Les valeurs des attributs sont des chaînes de caractères de 100 caractères maximum. Les attributs doivent être définis avant le début de la trace ; modifier un attribut après le début est ignoré. Cette limitation est liée aux performances : fixer des attributs après le début nécessiterait une synchronisation supplémentaire.

Seuils de performance et alertes

Les seuils sont des valeurs limites configurables pour les métriques, au-delà desquelles Firebase Performance génère un avertissement. Les seuils sont définis dans la console Firebase (Performance > Thresholds) pour chaque métrique automatique : temps de démarrage de l’application (à froid/à chaud), temps de rendu d’écran, requêtes HTTP lentes, temps de réponse HTTP. Vous pouvez définir des seuils globaux pour toutes les versions de l’application ou spécifiques pour des versions particulières.

Les alertes sont des notifications automatiques que Firebase envoie lorsqu’un seuil est dépassé. Les alertes peuvent être configurées par e-mail, webhook Slack, PagerDuty ou Cloud Functions (pour un traitement personnalisé). Chaque alerte contient : nom de la métrique, valeur actuelle, valeur du seuil, version de l’application, segment (appareil, pays). Les alertes permettent de réagir à la dégradation des performances avant qu’elle ne soit perceptible par les utilisateurs.

Seuils recommandés selon la norme industrielle (Google I/O 2025) : démarrage à froid — moins de 2 secondes, démarrage à chaud — moins de 1 seconde, rendu d’écran — moins de 500 ms, durée de requête HTTP — moins de 3000 ms (95e percentile), proportion de requêtes lentes — moins de 5 %. Pour les applications hautement concurrentielles (Social, E-commerce), les seuils cibles peuvent être plus stricts : démarrage à froid < 1,5 seconde, HTTP < 1000 ms.

Configuration des seuils dans la console Firebase

Dans la console Firebase, allez dans la section Performance, ouvrez l’onglet Thresholds. Pour chaque métrique, définissez la valeur seuil souhaitée et le pourcentage d’utilisateurs qui devrait être affecté par le dépassement. Par exemple : « considérer le démarrage à froid comme lent s’il dépasse 2 secondes pour plus de 10 % des utilisateurs ». Firebase affichera les valeurs actuelles des métriques et l’historique des dépassements pour vous aider à choisir des seuils réalistes.

Important : les seuils n’affectent pas la collecte de données, ils contrôlent uniquement la génération de notifications. Si le seuil est trop bas (par exemple, démarrage à froid 1 seconde, alors que 50 % des appareils démarrent en 3 secondes), les alertes arriveront constamment et deviendront un « bruit » que les développeurs cesseront de remarquer. Définissez des seuils basés sur les performances actuelles, puis resserrez-les progressivement à mesure que vous optimisez l’application.

Tableau de bord des performances dans la console Firebase

Le tableau de bord des performances affiche les métriques clés sous forme de séries temporelles ventilées par version d’application, appareil, pays, type de connexion et version d’OS. Pour chaque métrique, sont disponibles : moyenne, médiane, 95e percentile, 99e percentile. Le 95e percentile est la métrique la plus informative pour l’évaluation des performances, car il montre comment l’application fonctionne sur les appareils faibles, en ignorant les valeurs aberrantes.

Le tableau de bord prend en charge la comparaison de versions : sélectionnez deux versions de l’application (actuelle et précédente) pour une comparaison visuelle des métriques. Si après une mise à jour, le 95e percentile du temps de démarrage passe de 2,1 à 3,4 secondes — la régression est évidente, et vous devez trouver le commit qui a provoqué le ralentissement. Firebase Performance s’intègre avec GitHub, GitLab et Bitbucket, permettant de lier les changements de métriques à des commits spécifiques.

Exemples de code pour Performance Monitoring

Voyons des exemples d’intégration de Firebase Performance Monitoring dans une application Android avec Kotlin. Le code démontre la création d’une trace personnalisée pour mesurer le chargement d’un fil d’actualité, l’ajout d’un attribut HTTP pour une requête non interceptée automatiquement et l’utilisation de Trace pour mesurer le temps de traitement d’image. Tous les exemples tiennent compte de la possibilité de désactiver le traçage via Remote Config.

Avant utilisation, ajoutez la dépendance : implementation("com.google.firebase:firebase-perf") via Firebase BOM. Pour l’instrumentation automatique, aucune configuration supplémentaire n’est nécessaire — le SDK intercepte les opérations standard automatiquement après l’ajout de la dépendance.

Trace personnalisée pour le chargement de fil

Le premier exemple — mesure du temps de chargement du fil d’actualité depuis le serveur. La trace encapsule l’opération asynchrone fetchFeed, qui récupère les données du réseau et analyse JSON. Des attributs personnalisés ont été ajoutés à la trace : source de données (cache ou réseau) et nombre de publications reçues. Cela permet de segmenter les données et de comprendre dans quelles conditions le fil charge le plus lentement.

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 fonction loadFeedWithTrace prend un paramètre source (« cache » ou « network »), qui est utilisé comme attribut de la trace. Après la fin de l’opération asynchrone, la trace s’arrête dans un bloc finally, garantissant l’arrêt même en cas d’exception. La métrique items_count permet d’analyser comment le nombre de publications affecte le temps de chargement. Dans la console Firebase, vous pouvez filtrer les traces par l’attribut source et voir que le chargement via le réseau est 3 fois plus lent que via le cache.

Attribut HTTP pour requête non standard

Le deuxième exemple — attribut HTTP pour une requête effectuée via WebSocket (non interceptée automatiquement). La classe HttpMetric est utilisée, permettant d’enregistrer manuellement une requête URL, sa méthode, son code de réponse et sa taille. Firebase affichera cette requête dans la section Requêtes réseau avec les requêtes interceptées automatiquement.

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

Dans l’exemple, sendWithHttpMetric utilise newHttpMetric pour enregistrer un appel HTTP non standard. Le SDK ne l’intercepte pas automatiquement, donc le développeur définit manuellement l’URL, la méthode, le code de réponse et les tailles. Il est important de définir l’URL sans paramètres de requête (pour la sécurité et l’agrégation) — c’est-à-dire /data, pas /data?token=abc. Firebase regroupe automatiquement les modèles d’URL identiques.

Mesure du temps de traitement d’image

Le troisième exemple montre la mesure du temps de traitement d’image (compression, redimensionnement) à l’aide d’une trace personnalisée. Dans ce cas, la trace encapsule une opération synchrone, mais pour la production, utilisez des coroutines ou RxJava pour éviter de bloquer le 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 fonction compressImage mesure le temps de compression d’image en JPEG avec une qualité de 80 %. L’attribut format permet de comparer à l’avenir le temps de compression JPEG par rapport à WebP. La métrique output_size_kb montre l’efficacité de la compression. Dans la console Firebase, vous pouvez voir la distribution : sur les appareils faibles (Android d’entrée de gamme), la compression prend 4 fois plus de temps que sur les appareils haut de gamme, ce qui peut être la cause de retards lors du téléchargement d’images vers le serveur.

Comment améliorer les performances grâce aux données

Firebase Performance fournit des données mais n’offre pas de solutions toutes faites. L’analyse des métriques nécessite de comprendre les causes typiques de dégradation des performances pour chaque métrique. Voyons les principaux modèles de dégradation et comment les diagnostiquer à l’aide des données de Performance Monitoring. Approche : trouver une anomalie dans une métrique → vérifier les causes typiques → appliquer l’optimisation → vérifier le résultat après une semaine.

Démarrage à froid lent (> 2 secondes) : causes — initialisation lourde du SDK dans Application.onCreate (analyses, rapports de crash, SDK cartes), chargement de ressources volumineuses (polices, thèmes), opérations synchrones dans le thread principal au démarrage. Solutions : initialisation paresseuse du SDK, chargement différé des ressources, utilisation de l’API SplashScreen (Android 12+) pour afficher un espace réservé pendant l’initialisation. Firebase Performance montrera quelle version de l’application a commencé à ralentir — vérifiez quelles dépendances ont été ajoutées ou mises à jour.

Rendu d’écran lent (> 500 ms) : causes — hiérarchie de vues complexe (ConstraintLayout imbriqué, multiples fragments), chargement de données dans le thread UI (réseau ou disque), opérations de dessin lourdes (grandes images, vues personnalisées). Solutions : optimiser la hiérarchie de mise en page (Layout Inspector dans Android Studio), décharger les données vers le thread d’arrière-plan, mettre en cache les images via Glide ou Coil. Utilisez le filtre de rendu d’écran dans Firebase pour trouver l’écran le plus lent et l’optimiser en premier.

Optimisation des requêtes réseau

Requêtes HTTP lentes (> 3 secondes) : causes — serveur lent, grandes charges utiles, absence de mise en cache, protocole sous-optimal (HTTP/1.1 au lieu de HTTP/2), résolution DNS. Solutions : vérifiez le côté serveur (disponibilité, latence), réduisez la taille de la réponse (pagination, GraphQL, protobuf au lieu de JSON), activez la mise en cache via les en-têtes HTTP (Cache-Control), utilisez OkHttp Interceptor pour ajouter des délais d’attente et une logique de réessai.

Firebase Performance affiche la distribution temporelle de la requête : résolution DNS, handshake TCP, handshake TLS, envoi de la requête, réception de la réponse. Si la majeure partie du temps est consacrée au DNS — utilisez le préchargement DNS (OkHttp DNS-over-HTTPS). Si au TLS — utilisez la reprise de session et l’ajustement des suites de chiffrement. Si à la réception de la réponse — vérifiez la taille de la réponse et la vitesse du réseau de l’utilisateur. Les données Firebase permettent de localiser le problème au niveau du protocole, au lieu de simplement dire « la requête est lente ».

Intégration Remote Config pour désactiver le traçage

Pour la production, il est recommandé d’ajouter un drapeau Remote Config performance_tracing_enabled, qui permet de désactiver à distance les traces personnalisées. Si le SDK Firebase Performance côté client génère trop de données ou affecte les performances (sur les appareils faibles), vous pouvez désactiver les traces pour tous les utilisateurs, en ne laissant que les métriques automatiques, qui ont un impact minimal.

Exemple de logique : au démarrage de l’application, vérifiez le paramètre Remote Config performance_tracing_enabled. S’il est false — tous les appels à Firebase.performance.newTrace() renvoient un objet factice qui ne collecte pas de données. Ceci est implémenté via une classe wrapper qui vérifie le drapeau avant de créer une trace. Cette approche permet d’activer le traçage détaillé pour des utilisateurs spécifiques (testeurs bêta, développeurs) sans affecter l’ensemble de l’audience.