Dépannage et FAQ sur la surveillance des performances

Comment afficher les messages de journal pour les événements de performances

1. Ouvrez les outils de développement de votre navigateur (par exemple, l'onglet Réseau pour Chrome Dev Tools ou dans le Moniteur réseau pour Firefox ).

2. Actualisez votre application Web dans le navigateur.

3. Vérifiez vos messages de journal pour tout message d'erreur.

4. Après quelques secondes, recherchez un appel réseau vers firebaselogging.googleapis.com dans les outils de développement de votre navigateur. La présence de cet appel réseau montre que le navigateur envoie des données de performances à Firebase.

Si votre application n'enregistre pas les événements de performances, consultez les conseils de dépannage .

Ajout du SDK à l'application, mais la console dit toujours d'ajouter le SDK

Firebase peut détecter si vous avez ajouté avec succès le SDK de surveillance des performances à votre application lorsqu'il reçoit des informations sur les événements (telles que les interactions avec l'application) de votre application. Généralement, dans les 10 minutes suivant le démarrage de votre application, le tableau de bord Performances de la console Firebase affiche un message « SDK détecté ». Puis, dans les 30 minutes, le tableau de bord affiche les premières données traitées.

Si plus de 10 minutes se sont écoulées depuis que vous avez ajouté la dernière version du SDK à votre application et que vous ne voyez toujours aucun changement, vérifiez vos messages de journal pour vous assurer que Performance Monitoring enregistre les événements. Essayez les étapes de dépannage appropriées décrites ci-dessous pour résoudre un message de détection retardée du SDK.

La console indique que le SDK est détecté, mais aucune donnée n'est affichée

Performance Monitoring traite les données d'événements de performances avant de les afficher dans le tableau de bord Performances .

Si plus de 24 heures se sont écoulées depuis l'apparition du message « SDK détecté » et que vous ne voyez toujours pas de données, vérifiez le tableau de bord d'état de Firebase au cas où il y aurait une panne connue. S'il n'y a pas de panne, contactez l'assistance Firebase .

L'application n'enregistre pas les événements de performances

Si vous ne voyez pas les messages de journal pour les événements de performances , essayez les étapes de dépannage suivantes :

1. Assurez-vous que le SDK de surveillance des performances est correctement initialisé dans votre application.

2. Assurez-vous que le SDK de surveillance des performances n'est pas désactivé via l'indicateur suivant :

   • performance.instrumentationEnabled

3. Assurez-vous que la mise en cache de votre navigateur est désactivée, sinon le navigateur risque de ne pas récupérer de nouveaux paramètres d'instrumentation.

4. Fermez, puis rouvrez l'onglet de la page Web. Vérifiez à nouveau la journalisation.

   Si vous venez d'ajouter le SDK de surveillance des performances à votre application, vous devrez peut-être redémarrer complètement votre application pour que le SDK commence à fonctionner.

5. Si vous ne trouvez rien de désactivé dans votre application, contactez l'assistance Firebase .

Le tableau de bord des performances ne contient pas les premières données de délai d'entrée

Si vous ne voyez pas de données pour la première mesure du délai d'entrée , essayez les étapes de dépannage suivantes :

1. Sachez que la surveillance des performances enregistre uniquement la première mesure du délai d'entrée lorsqu'un utilisateur clique sur la page Web dans les 5 premières secondes suivant le chargement de la page.

2. Assurez-vous d'avoir configuré votre application pour mesurer cette métrique. La première mesure du délai d'entrée nécessite une configuration manuelle . Plus précisément, vous devez ajouter la bibliothèque polyfill pour cette métrique. Pour les instructions d'installation, reportez-vous à la documentation de la bibliothèque.

   Notez que l’ajout de cette bibliothèque polyfill n’est pas requis pour que Performance Monitoring puisse signaler d’autres métriques d’application Web.

Le tableau de bord des performances ne contient pas de données de trace personnalisées

Voyez-vous des données de performances pour les traces collectées automatiquement , mais pas pour les traces de code personnalisé ? Essayez les étapes de dépannage suivantes :

1. Vérifiez la configuration des traces de code personnalisées instrumentées via l' API Trace , notamment les suivantes :

   • Les noms des traces de code personnalisé et des métriques personnalisées doivent répondre aux exigences suivantes : pas d'espace de début ou de fin, pas de caractère de soulignement ( _ ) de début et la longueur maximale est de 32 caractères.
   • Toutes les traces doivent être démarrées et arrêtées. Toute trace qui n'est pas démarrée, arrêtée ou arrêtée avant d'être démarrée ne sera pas enregistrée.

   Notez que si vous utilisez la méthode record() , vous n'avez pas besoin de démarrer ou d'arrêter explicitement votre trace.

2. Assurez-vous que la collecte de données de surveillance des performances n'est pas désactivée via l'indicateur suivant :

   • performance.dataCollectionEnabled

     Cet indicateur contrôle la collecte de données pour les traces de code personnalisé uniquement (pas toutes les données).

3. Vérifiez vos messages de journal pour vous assurer que Performance Monitoring enregistre les traces de code personnalisé attendues.

4. Si la surveillance des performances enregistre les événements, mais qu'aucune donnée ne s'affiche après 24 heures, contactez l'assistance Firebase .

Le tableau de bord des performances ne contient pas de données de requête réseau

S'il vous manque des données de requête réseau, tenez compte des points suivants :

• La surveillance des performances collecte automatiquement les métriques pour les requêtes réseau signalées par l'API du navigateur. Ces rapports n'incluent pas les requêtes réseau ayant échoué.

• En fonction du comportement de votre code et des bibliothèques réseau utilisées par votre code, l'analyse des performances peut générer uniquement des rapports sur les requêtes réseau terminées. Cela signifie que les connexions HTTP/S laissées ouvertes risquent de ne pas être signalées.

Les données de requête réseau ne s'agrègent pas comme prévu

Apprenez-en davantage sur la façon dont Performance Monitoring regroupe les données de requêtes réseau sous des modèles d’URL.

Vous pouvez également essayer des modèles d'URL personnalisés !

Qu’est-il arrivé aux principaux problèmes de la carte Performances dans l’accueil du projet ?

Nous avons remplacé les principaux problèmes par des alertes récentes dans le prolongement de notre récente introduction d'alertes, qui vous avertissent automatiquement lorsque les seuils que vous avez définis sont franchis. Les problèmes sont désormais obsolètes et remplacés par des alertes.

Le sélecteur d'applications en haut de la carte Performance filtre les entrées d'alerte sous Alertes récentes . Seules les trois alertes les plus récentes pour la ou les applications sélectionnées sont affichées.

Pour en savoir plus sur les alertes, consultez Configurer des alertes pour les problèmes de performances .

Qu’est-il arrivé à la possibilité de définir des seuils de problèmes dans la console ?

La surveillance des performances prend en charge les alertes pour les métriques qui dépassent les seuils définis. Pour éviter toute confusion avec ces seuils configurables pour les mesures de performances, nous avons supprimé la possibilité de configurer des seuils pour les problèmes .

Qu'est-il arrivé aux informations de détails et de métriques dans la console Firebase ?

Nous avons remplacé les pages Détails et Métriques par une interface utilisateur (UI) centralisée et récemment repensée pour améliorer la façon dont vous résolvez les problèmes. Cette nouvelle interface utilisateur de dépannage offre les mêmes fonctionnalités de base que celles proposées par Details and Metrics. Pour en savoir plus sur le dépannage, consultez Afficher plus de données pour une trace spécifique .

Pourquoi le nombre d’échantillons n’est-il pas celui auquel je m’attendais ?

La surveillance des performances collecte les données de performances des appareils utilisateur de votre application. Si votre application compte de nombreux utilisateurs ou si l'application génère une grande quantité d'activité de performances, la surveillance des performances peut limiter la collecte de données à un sous-ensemble d'appareils afin de réduire le nombre d'événements traités. Ces limites sont suffisamment élevées pour que, même avec moins d'événements, les valeurs des mesures restent représentatives de l'expérience de votre utilisateur dans l'application.

Pour gérer le volume de données que nous collectons, Performance Monitoring utilise les options d'échantillonnage suivantes :

• Limitation du débit sur l'appareil : pour empêcher un appareil d'envoyer des rafales soudaines de traces, nous limitons le nombre de traces de code et de requêtes réseau envoyées depuis un appareil à 300 événements toutes les 10 minutes. Cette approche protège l'appareil des instruments en boucle qui peuvent envoyer de grandes quantités de données de performances, et empêche un seul appareil de fausser les mesures de performances.

• Échantillonnage dynamique : la surveillance des performances collecte quotidiennement une limite d'environ 100 millions d'événements pour les traces de code et 100 millions pour les traces de requêtes réseau par application pour tous les utilisateurs de l'application. Un taux d'échantillonnage dynamique est récupéré sur les appareils (à l'aide de Firebase Remote Config) pour déterminer si un appareil aléatoire doit capturer et envoyer des traces. Un périphérique qui n'est pas sélectionné pour l'échantillonnage n'envoie aucun événement. Le taux d'échantillonnage dynamique est spécifique à l'application et s'ajuste pour garantir que le volume global des données collectées reste inférieur à la limite.

  Les sessions utilisateur envoient des données supplémentaires et détaillées à partir de l'appareil d'un utilisateur, ce qui nécessite davantage de ressources pour capturer et envoyer les données. Pour minimiser l'impact des sessions utilisateur, la surveillance des performances peut également limiter le nombre de sessions.

• Limitation du débit côté serveur : pour garantir que les applications ne dépassent pas la limite d'échantillonnage, l'analyse des performances peut utiliser l'échantillonnage côté serveur pour supprimer certains événements reçus des appareils. Bien que ce type de limitation ne modifie pas l'efficacité de nos métriques, il peut entraîner des changements mineurs de modèle, notamment les suivants :

  • Le nombre de traces peut différer du nombre de fois qu'un morceau de code a été exécuté.
  • Les traces étroitement couplées dans le code peuvent chacune avoir un nombre d'échantillons différent.

Qu'est-il arrivé à l'onglet Problèmes dans la console ?

Nous avons remplacé l'onglet Problèmes par l'introduction d'alertes, qui vous avertissent automatiquement lorsque les seuils que vous définissez sont dépassés. Vous n'avez plus besoin de vérifier manuellement la console Firebase pour déterminer l'état d'un seuil. Pour en savoir plus sur les alertes, consultez Configurer des alertes pour les problèmes de performances .

Qu'est-il arrivé aux onglets Sur l'appareil et Réseau dans la console ? Comment puis-je visualiser les traces qui se trouvaient sur ces pages ?

Nous avons repensé la section Surveillance des performances de la console Firebase afin que l'onglet Tableau de bord affiche vos métriques clés et toutes vos traces dans un seul espace. Dans le cadre de la refonte, nous avons supprimé les pages Sur appareil et Réseau .

Le tableau des traces au bas de l'onglet Tableau de bord contient les mêmes informations que celles affichées par les onglets Sur l'appareil et Réseau , mais avec quelques fonctionnalités supplémentaires, notamment la possibilité de trier vos traces en fonction du pourcentage de variation pour une métrique spécifique. Pour afficher toutes les métriques et données d'une trace spécifique, cliquez sur le nom de la trace dans le tableau des traces.

Affichez vos traces dans les sous-onglets suivants du tableau des traces :

• Traces de requêtes réseau (prêtes à l'emploi et personnalisées) – Sous-onglet Requêtes réseau
• Traces de code personnalisé — Sous-onglet Traces personnalisées
• Traces de démarrage d'application, d'application au premier plan et d'application en arrière-plan – sous-onglet Traces personnalisées
• Traces de rendu d'écran — Sous-onglet Rendu d'écran
• Traces de chargement de page — Sous-onglet de chargement de page

Pour plus de détails sur le tableau des traces et l'affichage des métriques et des données, visitez la page de présentation de la console ( iOS+ | Android | Web ).

Pourquoi le nombre d’images lentes et figées n’est-il pas celui auquel je m’attendais ?

Les images à rendu lent et les images gelées sont calculées avec un taux de rafraîchissement de l'appareil supposé de 60 Hz. Si le taux de rafraîchissement d'un appareil est inférieur à 60 Hz, chaque image aura un temps de rendu plus lent car moins d'images sont rendues par seconde. Des temps de rendu plus lents peuvent entraîner le signalement d'images plus lentes ou gelées, car davantage d'images seront rendues plus lentement ou se figeront. Cependant, si le taux de rafraîchissement d'un appareil est supérieur à 60 Hz, chaque image aura un temps de rendu plus rapide. Cela peut entraîner le signalement d'un moins grand nombre d'images lentes ou gelées. Il s’agit d’une limitation actuelle du SDK de surveillance des performances.

Comment puis-je ajouter le SDK JS Performance Monitoring, plus petit et avec espace de noms (le SDK « autonome ») à mon application Web ?

Si la surveillance des performances est le seul produit Firebase de votre application, vous pouvez utiliser le SDK de surveillance des performances autonomes (et le script d'en-tête recommandé ci-dessous) si vous êtes intéressé:

• Utilisation d'une bibliothèque d'espionnage
• Réduire la taille de votre package SDK
• retardant l'initialisation du SDK jusqu'à ce que votre page charge de

Pour inclure le SDK de surveillance des performances autonomes dans votre application et retarder son initialisation après la charge de votre page:

1. Ajoutez le script suivant à l'en-tête de votre fichier d'index.
2. Assurez-vous d'ajouter l'objet de configuration du projet Firebase de votre application.

(function(sa,fbc){function load(f,c){var a=document.createElement('script');
a.async=1;a.src=f;var s=document.getElementsByTagName('script')[0];
s.parentNode.insertBefore(a,s);}load(sa);
window.addEventListener('load',function(){firebase.initializeApp(fbc).performance()});
})(performance_standalone, firebaseConfig);

où,

• performance_standalone est 'https://www.gstatic.com/firebasejs/10.7.1/firebase-performance.js'
• firebaseConfig est l'objet Firebase Config de votre application

Le script ci-dessus charge de manière asynchrone le SDK autonome, puis initialise Firebase après les incendies de l'événement onload de la fenêtre. Cette tactique réduit l'impact que le SDK pourrait avoir sur les métriques de chargement de page puisque le navigateur a déjà signalé ses mesures de chargement lorsque vous initialisez le SDK.

(function(sdkSource, firebaseConfigObject) {
   function load(f, c) {
       // Creates a script tag to load the standalone SDK
       var sdkScript = document.createElement('script');

       // Sets it to an async script so that it doesn't interfere with page load
       sdkScript.async = 1;

       // Sets the source of the script
       sdkScript.src = f;

       // Inserts the script into the head of the page
       var s = document.getElementsByTagName('script')[0];
       s.parentNode.insertBefore(sdkScript, s);
   }

   // Calls the load method
   load(sdkSource);

   // Initializes the SDK only when the onload method is called
   window.addEventListener('load', function() {
       firebase.initializeApp(firebaseConfigObject).performance();
   });
})(performance_standalone, firebaseConfig);

Que signifient les données de performance «quasi-en temps réel»?

Les processus de surveillance des performances de la base de feu ont collecté des données de performance au fur et à mesure de leur arrivée, ce qui entraîne un affichage de données en temps réel dans la console Firebase. Les données traitées s'affichent dans la console dans les quelques minutes de sa collecte, d'où le terme "presque en temps réel".

Pour profiter du traitement des données presque réel, assurez-vous que votre application utilise une version SDK compatible en temps réel .

Comment m'approcher des données de performances en temps réel pour mon application?

Pour profiter du traitement des données presque réel, il vous suffit de vous assurer que votre application utilise une version SDK de surveillance des performances compatible avec le traitement des données en temps réel.

Ce sont les versions SDK compatibles en temps réel:

• iOS - v7.3.0 ou plus tard
• tvos - v8.9.0 ou version ultérieure
• Android - v19.0.10 ou version ultérieure (ou Firebase Android Bom V26.1.0 ou version ultérieure)
• Web - v7.14.0 ou version ultérieure

Notez que nous vous recommandons toujours d'utiliser la dernière version de SDK, mais toute version répertoriée ci-dessus permettra à la surveillance des performances de traiter vos données en temps quasi réel.

Quelles versions du SDK de surveillance des performances sont considérées comme compatibles en temps réel?

Ce sont les versions SDK compatibles avec le traitement des données en temps réel:

• iOS - v7.3.0 ou plus tard
• tvos - v8.9.0 ou version ultérieure
• Android - v19.0.10 ou version ultérieure (ou Firebase Android Bom V26.1.0 ou version ultérieure)
• Web - v7.14.0 ou version ultérieure

Notez que nous vous recommandons toujours d'utiliser la dernière version de SDK, mais toute version répertoriée ci-dessus permettra à la surveillance des performances de traiter vos données en temps quasi réel.

Que se passe-t-il si je ne mets pas à jour mon application pour utiliser une version SDK compatible en temps réel?

Si votre application n'utilise pas de version SDK compatible en temps réel, vous verrez toujours toutes les données de performances de votre application dans la console Firebase. Cependant, l'affichage des données de performance sera retardé d'environ 36 heures à partir du moment de sa collecte.

J'ai mis à jour une version SDK compatible en temps réel, mais certains de mes utilisateurs sont toujours sur les anciennes versions de mon application. Dois-je continuer à voir leurs données de performance dans la console Firebase?

Oui! Quelle que soit la version SDK qu'une instance d'application utilise, vous verrez des données de performances de tous vos utilisateurs.

Cependant, si vous envisagez des données récentes (moins de 36 heures), les données affichées proviennent des utilisateurs d'instances d'applications à l'aide d'une version SDK compatible en temps réel. Les données non récentes , cependant, incluent les données de performance de toutes les versions de votre application.