Cette page fournit des conseils de dépannage pour démarrer avec la surveillance des performances ou utiliser les fonctionnalités et les outils de surveillance des performances.
Premières vérifications pour le dépannage
Les deux vérifications suivantes sont les meilleures pratiques générales recommandées à tous avant de poursuivre le dépannage.
1. Vérifiez les messages du journal pour les événements de performance
Vérifiez vos messages de journal pour vous assurer que le SDK de surveillance des performances capture les événements de performances.
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 ).
Actualisez votre application Web dans le navigateur.
Vérifiez vos messages de journal pour tout message d'erreur.
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 performance, consultez les conseils de dépannage .
2. Vérifiez le tableau de bord d'état de Firebase
Vérifiez le tableau de bord d'état de Firebase en cas de panne connue pour Firebase ou pour la surveillance des performances.
Premiers pas avec la surveillance des performances
Si vous débutez avec la surveillance des performances ( iOS+ | Android | Web ), les conseils de dépannage suivants peuvent vous aider à résoudre les problèmes impliquant la détection du SDK par Firebase ou l'affichage de vos premières données de performances dans la console Firebase.
Firebase peut détecter si vous avez correctement ajouté le SDK de surveillance des performances à votre application lorsqu'il reçoit des informations sur les événements (comme 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 des performances de la console Firebase affiche un message "SDK détecté". Puis, dans les 30 minutes, le tableau de bord affiche les données traitées initiales.
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, consultez vos messages de journal pour vous assurer que la surveillance des performances 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.
Si vous développez encore localement, essayez de générer plus d'événements pour la collecte de données :
Servez et affichez votre application Web dans un environnement local.
Générez des événements en chargeant des sous-pages pour votre site, en interagissant avec votre application et/ou en déclenchant des requêtes réseau. Assurez-vous de garder l'onglet du navigateur ouvert pendant au moins 10 secondes après le chargement de la page.
Assurez-vous que votre objet de configuration Firebase est correctement ajouté à votre application et que vous n'avez pas modifié l'objet. Plus précisément, vérifiez les points suivants :
- L'ID de l'application Web Firebase (
appId
) dans l'objet de configuration est correct pour votre application. Recherchez votre ID d'application Firebase dans la fiche Vos applications de vos Paramètres du projet .
Si quelque chose ne va pas avec l'objet de configuration dans votre application, essayez ce qui suit :
Supprimez l'objet de configuration que vous avez actuellement dans votre application.
Suivez ces instructions pour obtenir un nouvel objet de configuration et l'ajouter à votre application Web.
- L'ID de l'application Web Firebase (
Si le SDK enregistre les événements et que tout semble être configuré correctement, mais que vous ne voyez toujours pas le message de détection du SDK ou les données traitées (après 2 heures), contactez l'assistance Firebase .
Assurez-vous que le SDK de surveillance des performances est correctement initialisé dans votre application.
Assurez-vous que le SDK de surveillance des performances n'est pas désactivé via l'indicateur suivant :
-
performance.instrumentationEnabled
-
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.
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 dans votre application, vous devrez peut-être redémarrer complètement votre application pour que le SDK commence à fonctionner.
Si vous ne trouvez aucun élément désactivé dans votre application, contactez l'assistance Firebase .
La surveillance des performances traite les données d'événement de performances avant de les afficher dans le tableau de bord des 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, consultez le tableau de bord d'état Firebase en cas de panne connue. S'il n'y a pas de panne, contactez l'assistance Firebase .
Dépannage général
Si vous avez ajouté le SDK avec succès et que vous utilisez la surveillance des performances dans votre application, les conseils de dépannage suivants peuvent vous aider à résoudre les problèmes généraux impliquant les fonctionnalités et les outils de surveillance des performances.
Si vous ne voyez pas de messages de journal pour les événements de performances , essayez les étapes de dépannage suivantes :
Assurez-vous que le SDK de surveillance des performances est correctement initialisé dans votre application.
Assurez-vous que le SDK de surveillance des performances n'est pas désactivé via l'indicateur suivant :
-
performance.instrumentationEnabled
-
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.
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 dans votre application, vous devrez peut-être redémarrer complètement votre application pour que le SDK commence à fonctionner.
Si vous ne trouvez aucun élément désactivé dans votre application, contactez l'assistance Firebase .
Si vous ne voyez pas de données pour la première statistique de délai de saisie , essayez les étapes de dépannage suivantes :
Sachez que la surveillance des performances enregistre uniquement la première métrique de délai d'entrée lorsqu'un utilisateur clique sur la page Web dans les 5 premières secondes après le chargement de la page.
Assurez-vous d'avoir configuré votre application pour mesurer cette métrique. La première métrique de 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 nécessaire pour que la surveillance des performances signale d'autres métriques d'application Web.
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 :
Vérifiez la configuration des traces de code personnalisées instrumentées via l' API Trace , en particulier les éléments suivants :
- Les noms des traces de code personnalisées et des métriques personnalisées doivent répondre aux exigences suivantes : pas d'espace blanc au début ou à la fin, pas de trait de soulignement (
_
) au 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 non démarrée, non arrêtée ou arrêtée avant le démarrage ne sera pas consigné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.- Les noms des traces de code personnalisées et des métriques personnalisées doivent répondre aux exigences suivantes : pas d'espace blanc au début ou à la fin, pas de trait de soulignement (
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).
Vérifiez vos messages de journal pour vous assurer que la surveillance des performances enregistre les traces de code personnalisé attendues.
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 .
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 demandes réseau ayant échoué.
En fonction du comportement de votre code et des bibliothèques de mise en réseau utilisées par votre code, la surveillance des performances peut uniquement générer des rapports sur les demandes réseau qui sont terminées. Cela signifie que les connexions HTTP/S qui restent ouvertes peuvent ne pas être signalées.
En savoir plus sur la façon dont la surveillance des performances agrège les données des requêtes réseau sous des modèles d'URL.
Vous pouvez également essayer des modèles d'URL personnalisés !
FAQ
Nous avons remplacé les problèmes les plus fréquents par des alertes récentes dans le prolongement de notre récente introduction des 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 fiche Performances filtre les entrées d'alerte sous Alertes récentes . Seules les trois alertes les plus récentes pour les applications sélectionnées sont affichées.
Pour en savoir plus sur les alertes, voir Configurer des alertes pour les problèmes de performances .
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 .
Nous avons remplacé les pages Détails et Métriques par une nouvelle interface utilisateur centralisée et 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 Détails et Métriques. Pour en savoir plus sur le dépannage, consultez Afficher plus de données pour une trace spécifique .
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és 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 de métrique soient toujours représentatives de l'expérience de l'application de votre utilisateur.
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 demande réseau envoyées depuis un appareil à 300 événements toutes les 10 minutes. Cette approche protège l'appareil des instrumentations en boucle qui peuvent envoyer de grandes quantités de données de performances et empêche qu'un seul appareil fausse les mesures de performances.
Échantillonnage dynamique : la surveillance des performances collecte environ 100 millions d'événements pour les traces de code et 100 millions pour les traces de demande 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 appareil 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 de données collectées reste inférieur à la limite.
Les sessions utilisateur envoient des données détaillées supplémentaires à 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 s'assurer que les applications ne dépassent pas la limite d'échantillonnage, la surveillance 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 statistiques, il peut entraîner des modifications mineures des modèles, notamment :
- Le nombre de traces peut différer du nombre de fois qu'un morceau de code a été exécuté.
- Les traces qui sont étroitement couplées dans le code peuvent chacune avoir un nombre différent d'échantillons.
Nous avons remplacé l'onglet Problèmes par l'introduction d'Alertes, qui vous avertit automatiquement lorsque les seuils que vous avez définis 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, voir Configurer des alertes pour les problèmes de performances .
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 l'appareil et Réseau .
Le tableau des traces au bas de l'onglet Tableau de bord contient les mêmes informations que les onglets Sur l'appareil et Réseau affichés, mais avec quelques fonctionnalités supplémentaires, notamment la possibilité de trier vos traces en fonction du pourcentage de changement 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 :
- Suivis des demandes réseau (à la fois prêts à l'emploi et personnalisés) — sous-onglet Demandes réseau
- Suivis de code personnalisés — sous-onglet Suivis personnalisés
- Démarrage de l'application, application au premier plan, suivis de l'application en arrière-plan — Sous-onglet Suivis personnalisés
- Traces de rendu d'écran — sous-onglet Rendu d'écran
- Traces de chargement de page — sous-onglet 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 ).
Les images de rendu lentes et les images gelées sont calculées avec un taux de rafraîchissement supposé de l'appareil 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 seront gelées. 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 réduire le nombre de trames lentes ou gelées signalées. Il s'agit d'une limitation actuelle du SDK de surveillance des performances.
If Performance Monitoring is the only Firebase product in your app, you can use the standalone Performance Monitoring SDK (and the recommended header script below) if you're interested in:
- using a namespaced library
- reducing your SDK package size
- delaying initialization of the SDK until after your page loads
To include the standalone Performance Monitoring SDK in your app and delay its initialization to after your page loads:
- Add the following script to the header of your index file.
- Make sure to add your app's Firebase project configuration object .
(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);
where,
- performance_standalone is
'https://www.gstatic.com/firebasejs/9.17.2/firebase-performance-standalone.js'
- firebaseConfig is your app's Firebase config object
The above script asynchronously loads the standalone SDK then initializes Firebase after the window's onload
event fires. This tactic reduces the impact that the SDK could have on page load metrics since the browser has already reported its loading metrics when you initialize the SDK.
Near real-time data processing and display
Firebase Performance Monitoring processes collected performance data as it comes in, which results in near real-time data display in the Firebase console. Processed data displays in the console within a few minutes of its collection, hence the term "near real-time".
To take advantage of near real-time data processing, make sure your app uses a real-time compatible SDK version .
To take advantage of near real-time data processing, you only need to make sure that your app uses a Performance Monitoring SDK version that's compatible with real-time data processing.
These are the real-time compatible SDK versions:
- iOS — v7.3.0 or later
- tvOS — v8.9.0 or later
- Android — v19.0.10 or later (or Firebase Android BoM v26.1.0 or later)
- Web — v7.14.0 or later
Note that we always recommend using the latest version of SDK, but any version listed above will enable Performance Monitoring to process your data in near real time.
These are the SDK versions compatible with real-time data processing:
- iOS — v7.3.0 or later
- tvOS — v8.9.0 or later
- Android — v19.0.10 or later (or Firebase Android BoM v26.1.0 or later)
- Web — v7.14.0 or later
Note that we always recommend using the latest version of SDK, but any version listed above will enable Performance Monitoring to process your data in near real time.
If your app doesn't use a real-time compatible SDK version, you will still see all your app's performance data in the Firebase console. However, the display of performance data will be delayed by roughly 36 hours from the time of its collection.
Yes! Regardless of which SDK version an app instance uses, you'll see performance data from all your users.
However, if you're looking at recent data (less than roughly 36 hours old), then the displayed data is from users of app instances using a real-time compatible SDK version. The non-recent data, though, includes performance data from all versions of your app.
Contacting Firebase Support
If you reach out to Firebase Support , always include your Firebase App ID. Find your Firebase App ID in the Your apps card of your Project settings .
,This page provides troubleshooting tips for getting started with Performance Monitoring or using Performance Monitoring features and tooling.
First checks for troubleshooting
The following two checks are general best practices recommended for anyone before further troubleshooting.
1. Check log messages for performance events
Check your log messages to be sure that the Performance Monitoring SDK is capturing performance events.
Open your browser's developer tools (for example, Network tab for Chrome Dev Tools or in the Network Monitor for Firefox ).
Refresh your web app in the browser.
Check your log messages for any error messages.
After a few seconds, look for a network call to
firebaselogging.googleapis.com
in your browser's developer tools. The presence of that network call shows that the browser is sending performance data to Firebase.
If your app isn't logging performance events, review the troubleshooting tips .
2. Check the Firebase Status Dashboard
Check the Firebase Status Dashboard in case there is a known outage for Firebase or for Performance Monitoring.
Getting started with Performance Monitoring
If you're getting started with Performance Monitoring ( iOS+ | Android | Web ), the following troubleshooting tips can help with issues that involve Firebase detecting the SDK or displaying your first performance data in the Firebase console.
Firebase can detect if you've successfully added the Performance Monitoring SDK to your app when it receives event information (like app interactions) from your app. Usually within 10 minutes of starting your app, the Performance dashboard of the Firebase console displays an "SDK detected" message. Then, within 30 minutes, the dashboard displays the initial processed data.
If it's been more than 10 minutes since you added the latest version of SDK to your app, and you're still not seeing any change, check your log messages to make sure that Performance Monitoring is logging events. Try the appropriate troubleshooting steps as described below to troubleshoot a delayed SDK detection message.
If you're still developing locally, try generating more events for data collection:
Serve and view your web app in a local environment.
Generate events by loading subpages for your site, interacting with your app, and/or triggering network requests. Make sure to keep the browser tab open for at least 10 seconds after the page loads.
Make sure that your Firebase configuration object is correctly added to your app and that you haven't modified the object. Specifically, check the following:
- The Firebase Web App ID (
appId
) in the config object is correct for your app. Find your Firebase App ID in the Your apps card of your Project settings .
If anything seems wrong with the config object in your app, try the following:
Delete the config object that you currently have in your app.
Follow these instructions to obtain a new config object and add it to your web app.
- The Firebase Web App ID (
If the SDK is logging events and everything seems to be set up correctly, but you're still not seeing the SDK detection message or processed data (after 2 hours), contact Firebase Support .
Make sure that the Performance Monitoring SDK is correctly initialized in your app.
Make sure that the Performance Monitoring SDK is not disabled through the following flag:
-
performance.instrumentationEnabled
-
Make sure that your browser caching is disabled, otherwise the browser might not pick up any new instrumentation settings.
Close, then reopen the webpage tab. Check for logging again.
If you just added the Performance Monitoring SDK in your app, you might need to fully restart your app for the SDK to start working.
If you can't find anything that's disabled in your app, contact Firebase Support .
Performance Monitoring processes performance event data before displaying it in the Performance dashboard .
If it's been more than 24 hours since the "SDK detected" message appeared , and you're still not seeing data, then check the Firebase Status Dashboard in case there is a known outage. If there is no outage, contact Firebase Support .
General troubleshooting
If you've successfully added the SDK and are using Performance Monitoring in your app, the following troubleshooting tips can help with general issues that involve Performance Monitoring features and tooling.
If you're not seeing log messages for performance events , try the following troubleshooting steps:
Make sure that the Performance Monitoring SDK is correctly initialized in your app.
Make sure that the Performance Monitoring SDK is not disabled through the following flag:
-
performance.instrumentationEnabled
-
Make sure that your browser caching is disabled, otherwise the browser might not pick up any new instrumentation settings.
Close, then reopen the webpage tab. Check for logging again.
If you just added the Performance Monitoring SDK in your app, you might need to fully restart your app for the SDK to start working.
If you can't find anything that's disabled in your app, contact Firebase Support .
If you're not seeing data for the first input delay metric , try the following troubleshooting steps:
Be aware that Performance Monitoring only records the first input delay metric when a user clicks on the web page within the first 5 seconds after page load.
Make sure that you've set up your app to measure this metric. The first input delay metric requires manual setup . Specifically, you need to add the polyfill library for this metric. For installation instructions, refer to the library's documentation .
Note that adding this polyfill library is not required for Performance Monitoring to report other web app metrics.
Are you seeing performance data for automatically collected traces but not for custom code traces ? Try the following troubleshooting steps:
Check the setup of custom code traces instrumented via the Trace API , especially the following:
- Names for custom code traces and custom metrics must meet the following requirements: no leading or trailing whitespace, no leading underscore (
_
) character, and max length is 32 characters. - All traces must be started and stopped. Any trace that is not started, not stopped, or stopped before started will not be logged.
Note that if you're using the
record()
method, then you don't need to explicitly start or stop your trace.- Names for custom code traces and custom metrics must meet the following requirements: no leading or trailing whitespace, no leading underscore (
Make sure that Performance Monitoring data collection is not disabled through the following flag:
performance.dataCollectionEnabled
This flag controls the collection of data for custom code traces only (not all data).
Check your log messages to make sure that Performance Monitoring is logging expected custom code traces.
If Performance Monitoring is logging events, but no data displays after 24 hours, contact Firebase Support .
If you're missing network request data, be aware of the following:
Performance Monitoring automatically collects metrics for network requests reported by the browser API. These reports do not include failed network requests.
Depending on the behavior of your code and networking libraries used by your code, Performance Monitoring might only report on network requests that are completed. This means that HTTP/S connections that are left open might not be reported.
Learn more about how Performance Monitoring aggregates network request data under URL patterns.
You can also try out custom URL patterns !
FAQ
We replaced Top Issues with Recent Alerts as a follow-up to our recent introduction of alerts, which automatically notify you when the thresholds you set are crossed. Issues are now deprecated and replaced by alerts.
The apps selector at the top of the Performance card filters the alert entries under Recent Alerts . Only the three most recent alerts for the app(s) selected are displayed.
To learn more about alerts, see Set up alerts for performance issues .
Performance Monitoring supports alerts for metrics that exceed defined thresholds. To avoid confusion with these configurable thresholds for performance metrics, we removed the ability to configure thresholds for issues .
We replaced the Details and Metrics pages with a newly redesigned, centralized user interface (UI) to improve how you troubleshoot issues. This new troubleshooting UI offers the same core functionality that Details and Metrics offered. To learn more about troubleshooting, see View more data for a specific trace .
Performance Monitoring collects performance data from your app's user devices. If your application has many users or if the app generates a large amount of performance activity, Performance Monitoring might limit data collection to a subset of devices to reduce the number of processed events. These limits are high enough so that, even with fewer events, the metric values are still representative of your user's app experience.
To manage the volume of data that we collect, Performance Monitoring uses the following sampling options:
On-device rate limiting : To prevent a device from sending sudden bursts of traces, we limit the number of code and network request traces sent from a device to 300 events every 10 mins. This approach protects the device from looped instrumentations that can send large amounts of performance data, and it prevents a single device from skewing the performance measurements.
Dynamic sampling : Performance Monitoring collects approximately 100M events for code traces and 100M for network request traces per app across all app users. A dynamic sampling rate is fetched on devices (using Firebase Remote Config) to determine whether a random device should capture and send traces. A device that is not selected for sampling does not send any events. The dynamic sampling rate is app-specific and adjusts to ensure that the overall volume of collected data remains below the limit.
User sessions send additional, detailed data from a user's device, requiring more resources to capture and send the data. To minimize the impact of user sessions, Performance Monitoring might also restrict the number of sessions.
Server-side rate limiting : To ensure that apps don't exceed the sampling limit, Performance Monitoring might use server-side sampling to drop some events received from devices. Although this type of limiting doesn't change the effectiveness of our metrics, it may cause minor pattern shifts, including the following:
- The number of traces can differ from the number of times that a piece of code was executed.
- Traces that are closely coupled in code may each have a different number of samples.
We replaced the Issues tab with the introduction of Alerts, which automatically notifies you when the thresholds you set are exceeded. You no longer need to manually check the Firebase console to determine the status of a threshold. To learn about Alerts, see Set up alerts for performance issues .
We've redesigned the Performance Monitoring section of the Firebase console so that the Dashboard tab displays your key metrics and all your traces in one space. As part of the redesign, we removed the On device and Network pages.
The traces table at the bottom of the Dashboard tab has all the same information that the On device and Network tabs displayed, but with some added features, including the ability to sort your traces by the percentage change for a specific metric. To view all the metrics and data for a specific trace, click the trace name in the traces table.
View your traces in the following subtabs of the traces table:
- Network request traces (both out-of-the-box and custom) — Network requests subtab
- Custom code traces — Custom traces subtab
- App start, app-in-foreground, app-in-background traces — Custom traces subtab
- Screen rendering traces — Screen rendering subtab
- Page load traces — Page load subtab
For details about the traces table and viewing metrics and data, visit the console overview page ( iOS+ | Android | Web ).
Slow rendering frames and frozen frames are calculated with an assumed device refresh rate of 60Hz. If a device refresh rate is lower than 60Hz, each frame will have a slower rendering time because fewer frames are rendered per second. Slower rendering times can cause more slow or frozen frames to be reported because more frames will be rendered slower or will freeze. However, if a device refresh rate is higher than 60Hz, each frame will have a faster rendering time. This can cause fewer slow or frozen frames to be reported. This is a current limitation in the Performance Monitoring SDK.
If Performance Monitoring is the only Firebase product in your app, you can use the standalone Performance Monitoring SDK (and the recommended header script below) if you're interested in:
- using a namespaced library
- reducing your SDK package size
- delaying initialization of the SDK until after your page loads
To include the standalone Performance Monitoring SDK in your app and delay its initialization to after your page loads:
- Add the following script to the header of your index file.
- Make sure to add your app's Firebase project configuration object .
(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);
where,
- performance_standalone is
'https://www.gstatic.com/firebasejs/9.17.2/firebase-performance-standalone.js'
- firebaseConfig is your app's Firebase config object
The above script asynchronously loads the standalone SDK then initializes Firebase after the window's onload
event fires. This tactic reduces the impact that the SDK could have on page load metrics since the browser has already reported its loading metrics when you initialize the SDK.
Near real-time data processing and display
Firebase Performance Monitoring processes collected performance data as it comes in, which results in near real-time data display in the Firebase console. Processed data displays in the console within a few minutes of its collection, hence the term "near real-time".
To take advantage of near real-time data processing, make sure your app uses a real-time compatible SDK version .
To take advantage of near real-time data processing, you only need to make sure that your app uses a Performance Monitoring SDK version that's compatible with real-time data processing.
These are the real-time compatible SDK versions:
- iOS — v7.3.0 or later
- tvOS — v8.9.0 or later
- Android — v19.0.10 or later (or Firebase Android BoM v26.1.0 or later)
- Web — v7.14.0 or later
Note that we always recommend using the latest version of SDK, but any version listed above will enable Performance Monitoring to process your data in near real time.
These are the SDK versions compatible with real-time data processing:
- iOS — v7.3.0 or later
- tvOS — v8.9.0 or later
- Android — v19.0.10 or later (or Firebase Android BoM v26.1.0 or later)
- Web — v7.14.0 or later
Note that we always recommend using the latest version of SDK, but any version listed above will enable Performance Monitoring to process your data in near real time.
If your app doesn't use a real-time compatible SDK version, you will still see all your app's performance data in the Firebase console. However, the display of performance data will be delayed by roughly 36 hours from the time of its collection.
Yes! Regardless of which SDK version an app instance uses, you'll see performance data from all your users.
However, if you're looking at recent data (less than roughly 36 hours old), then the displayed data is from users of app instances using a real-time compatible SDK version. The non-recent data, though, includes performance data from all versions of your app.
Contacting Firebase Support
If you reach out to Firebase Support , always include your Firebase App ID. Find your Firebase App ID in the Your apps card of your Project settings .