このページでは、Performance Monitoring を開始するため、または Performance Monitoring の機能とツールを使用するためのトラブルシューティングのヒントを提供します。
トラブルシューティングの最初のチェック
次の 2 つのチェックは、さらにトラブルシューティングを行う前に推奨される一般的なベスト プラクティスです。
1. パフォーマンス イベントのログ メッセージを確認する
ログ メッセージをチェックして、Performance Monitoring SDK がパフォーマンス イベントをキャプチャしていることを確認してください。
次のように、デバッグ ロギングを有効にします。
- Xcode (最小 v13.3.1) で、[ Product ] > [ Scheme ] > [ Edit scheme ] を選択します。
- 左側のメニューから [実行] を選択し、[引数] タブを選択します。
- [起動時に渡される引数] セクションで、
-FIRDebugEnabledを追加します。
ログ メッセージでエラー メッセージを確認します。
Performance Monitoring は、ログ メッセージをフィルタリングできるように、ログ メッセージに
Firebase/Performanceのタグを付けます。Performance Monitoring がパフォーマンス イベントをログに記録していることを示す次の種類のログを確認します。
-
Logging trace metric: TRACE_NAME , FIREBASE_PERFORMANCE_CONSOLE_URL -
Logging network request trace: URL
-
URL をクリックして、Firebase コンソールでデータを表示します。ダッシュボードでデータが更新されるまで、少し時間がかかる場合があります。
アプリがパフォーマンス イベントをログに記録していない場合は、トラブルシューティングのヒントを確認してください。
2. Firebase ステータス ダッシュボードを確認する
Firebase または Performance Monitoring の既知の停止がある場合は、 Firebase ステータス ダッシュボードを確認してください。
パフォーマンス監視の開始
Performance Monitoring ( iOS+ | Android | Web ) の使用を開始する場合、次のトラブルシューティングのヒントは、Firebase が SDK を検出する、または Firebase コンソールに最初のパフォーマンス データを表示することに関連する問題に役立ちます。
Firebase は、アプリからイベント情報 (アプリ インタラクションなど) を受け取ると、Performance Monitoring SDK がアプリに正常に追加されたかどうかを検出できます。通常、アプリを起動してから 10 分以内に、Firebase コンソールのパフォーマンスダッシュボードに「SDK が検出されました」というメッセージが表示されます。その後、30 分以内に、ダッシュボードに最初に処理されたデータが表示されます。
最新バージョンの SDK をアプリに追加してから 10 分以上経過しても変化が見られない場合は、ログ メッセージをチェックして、Performance Monitoring がイベントをログに記録していることを確認してください。以下に説明されている適切なトラブルシューティング手順を試して、遅れた SDK 検出メッセージのトラブルシューティングを行ってください。
まだローカルで開発している場合は、データ収集用のイベントをさらに生成してみてください。
シミュレーターまたはテスト デバイスを使用してアプリの開発を続けます。
アプリのバックグラウンドとフォアグラウンドを数回切り替えたり、画面間を移動してアプリを操作したり、ネットワーク リクエストをトリガーしたりして、イベントを生成します。
Firebase 構成ファイル(
Google-Service-Info.plist) がアプリに正しく追加され、ファイルが変更されていないことを確認してください。具体的には、次の点を確認してください。構成ファイル名には、
(2)のような追加の文字は追加されません。構成ファイルは XCode プロジェクトのルートにあり、正しいターゲットに追加されます。
構成ファイルにリストされている Firebase Apple アプリ ID (
GOOGLE_APP_ID) は、アプリに対して正しいものです。 Project settingsのYour appsカードで Firebase アプリ ID を見つけます。
アプリの構成ファイルに何か問題があると思われる場合は、次のことを試してください。
現在アプリにある構成ファイルを削除します。
次の手順に従って、新しい構成ファイルをダウンロードし、Apple アプリに追加します。
SDK がイベントをログに記録し、すべてが正しく設定されているように見えても、SDK 検出メッセージまたは処理されたデータが表示されない場合 (2 時間後)、 Firebase サポートにお問い合わせください。
Info.plistファイルで次のいずれかのフラグを使用して、 Performance Monitoring SDK が無効になっていないことを確認してください。-
firebase_performance_collection_enabled -
firebase_performance_collection_deactivated
-
アプリで無効になっているものが見つからない場合は、 Firebase サポートにお問い合わせください。
Performance Monitoring は、パフォーマンス イベント データを処理してから、パフォーマンスダッシュボードに表示します。
「SDK が検出されました」というメッセージが表示されてから 24 時間以上経過してもデータが表示されない場合は、既知の停止がないかFirebase ステータス ダッシュボードを確認してください。停止がない場合は、 Firebase サポートにお問い合わせください。
一般的なトラブルシューティング
SDK を正常に追加し、アプリで Performance Monitoring を使用している場合、次のトラブルシューティングのヒントは、Performance Monitoring の機能とツールに関連する一般的な問題に役立ちます。
パフォーマンス イベントのログ メッセージが表示されない場合は、次のトラブルシューティング手順を試してください。
Info.plistファイルで次のいずれかのフラグを使用して、 Performance Monitoring SDK が無効になっていないことを確認してください。-
firebase_performance_collection_enabled -
firebase_performance_collection_deactivated
-
アプリで無効になっているものが見つからない場合は、 Firebase サポートにお問い合わせください。
画面レンダリング トレースのデータが欠落している場合は、次のトラブルシューティング手順を試してください。
自動収集されたトレースのパフォーマンス データは表示されますが、カスタム コード トレースのパフォーマンス データは表示されませんか?次のトラブルシューティング手順を試してください。
Trace APIを介してインストルメント化されたカスタム コード トレースの設定、特に以下を確認します。
- カスタム コード トレースとカスタム メトリクスの名前は、次の要件を満たす必要があります: 先頭または末尾に空白がないこと、先頭にアンダースコア (
_) 文字がないこと、および最大長が 32 文字であること。 - すべてのトレースを開始および停止する必要があります。開始されていない、停止されていない、または開始前に停止されたトレースはログに記録されません。
- カスタム コード トレースとカスタム メトリクスの名前は、次の要件を満たす必要があります: 先頭または末尾に空白がないこと、先頭にアンダースコア (
ログ メッセージをチェックして、Performance Monitoring が予想されるカスタム コード トレースをログに記録していることを確認します。
Performance Monitoring がイベントをログに記録しているが、24 時間経過してもデータが表示されない場合は、 Firebase サポートにお問い合わせください。
ネットワーク リクエスト データが見つからない場合は、次のトラブルシューティング手順を試してください。
ネットワーク ライブラリの非互換性を確認します。 Performance Monitoring は、次のネットワーク ライブラリを使用するネットワーク リクエストの指標を自動的に収集します。
- Swift の場合: URLSession および URLConnection
- Objective-C の場合: NSURLSession および NSURLConnection
ネットワーク リクエストのカスタム モニタリングを追加できることに注意してください。
次の点に注意してください。
コードとコードで使用されるネットワーク ライブラリの動作によっては、Performance Monitoring は完了したネットワーク リクエストのみを報告する場合があります。これは、開いたままの HTTP/S 接続が報告されない可能性があることを意味します。
Performance Monitoring は、無効な
Content-Typeヘッダーを含むネットワーク リクエストについては報告しません。ただし、Content-Typeヘッダーのないネットワーク リクエストは引き続き受け入れられます。
Performance Monitoring が URL パターンに基づいてネットワーク リクエスト データを集計する方法の詳細をご覧ください。
カスタム URL パターンを試すこともできます。
よくある質問
最近導入されたアラートのフォローアップとして、上位の問題を最近のアラートに置き換えました。アラートは、設定したしきい値を超えたときに自動的に通知します。問題は廃止され、アラートに置き換えられました。
[パフォーマンス] カードの上部にあるアプリ セレクターは、[最近のアラート] の下のアラート エントリをフィルター処理します。選択したアプリの最新の 3 つのアラートのみが表示されます。
アラートの詳細については、「パフォーマンスの問題に関するアラートを設定する」を参照してください。
Performance Monitoring は、定義されたしきい値を超えるメトリックのアラートをサポートしています。これらの設定可能なパフォーマンス メトリックのしきい値との混同を避けるため、問題のしきい値を設定する機能を削除しました。
問題のトラブルシューティング方法を改善するために、[詳細] ページと [メトリック] ページを新しく再設計された一元化されたユーザー インターフェイス (UI) に置き換えました。この新しいトラブルシューティング UI は、詳細とメトリクスが提供するのと同じコア機能を提供します。トラブルシューティングの詳細については、特定のトレースの詳細データを表示する を参照してください。
Performance Monitoring は、アプリのユーザー デバイスからパフォーマンス データを収集します。アプリケーションに多くのユーザーがいる場合、またはアプリが大量のパフォーマンス アクティビティを生成する場合、パフォーマンス モニタリングはデータ収集をデバイスのサブセットに制限して、処理されるイベントの数を減らすことがあります。これらの制限は十分に高いため、イベントが少なくても、メトリック値はユーザーのアプリ エクスペリエンスを表しています。
収集するデータ量を管理するために、Performance Monitoring は次のサンプリング オプションを使用します。
オンデバイス レート制限: デバイスがトレースの突然のバーストを送信するのを防ぐために、デバイスから送信されるコードおよびネットワーク リクエスト トレースの数を 10 分ごとに 300 イベントに制限します。このアプローチにより、大量のパフォーマンス データを送信できるループ インストルメンテーションからデバイスを保護し、1 つのデバイスがパフォーマンス測定値を歪めるのを防ぎます。
動的サンプリング: Performance Monitoring は、すべてのアプリ ユーザーのアプリごとに、コード トレースで約 1 億イベント、ネットワーク リクエスト トレースで 1 億イベントを収集します。デバイスでダイナミック サンプリング レートが取得され（Firebase Remote Config を使用）、ランダムなデバイスがトレースをキャプチャして送信する必要があるかどうかが判断されます。サンプリング対象として選択されていないデバイスは、イベントを送信しません。動的サンプリング レートはアプリ固有であり、収集されたデータの全体量が制限を下回るように調整されます。
ユーザー セッションは、ユーザーのデバイスから追加の詳細データを送信するため、データをキャプチャして送信するためにより多くのリソースが必要になります。ユーザー セッションの影響を最小限に抑えるために、Performance Monitoring はセッション数も制限する場合があります。
サーバー側のレート制限: アプリがサンプリング制限を超えないようにするために、Performance Monitoring はサーバー側のサンプリングを使用して、デバイスから受信した一部のイベントを破棄する場合があります。このタイプの制限によって指標の有効性が変わることはありませんが、次のような小さなパターンの変化が生じる可能性があります。
- トレースの数は、コードの一部が実行された回数とは異なる場合があります。
- コード内で密接に結合されているトレースは、それぞれ異なる数のサンプルを持つ場合があります。
[問題] タブが、設定したしきい値を超えたときに自動的に通知されるアラートの導入に置き換えられました。しきい値のステータスを判断するために、Firebase コンソールを手動で確認する必要がなくなりました。アラートの詳細については、「パフォーマンスの問題に関するアラートを設定する」を参照してください。
Firebase コンソールの [パフォーマンス モニタリング] セクションを再設計し、[ダッシュボード] タブに主要な指標とすべてのトレースが 1 つのスペースに表示されるようにしました。再設計の一環として、デバイスとネットワークのページを削除しました。
[ダッシュボード] タブの下部にあるトレース テーブルには、[デバイス上] および [ネットワーク] タブに表示されたものと同じ情報がすべて表示されますが、特定のメトリックの変化率でトレースを並べ替える機能など、いくつかの機能が追加されています。特定のトレースのすべてのメトリックとデータを表示するには、トレース テーブルでトレース名をクリックします。
トレース テーブルの次のサブタブでトレースを表示します。
- ネットワーク リクエスト トレース (標準とカスタムの両方) — [ネットワーク リクエスト] サブタブ
- カスタム コード トレース —カスタム トレースサブタブ
- アプリの開始、フォアグラウンドのアプリ、バックグラウンドのアプリのトレース —カスタム トレースサブタブ
- 画面レンダリング トレース —画面レンダリングサブタブ
- ページ ロード トレース —ページ ロードサブタブ
トレース テーブルと表示メトリックとデータの詳細については、コンソールの概要ページ ( iOS+ | Android | Web ) にアクセスしてください。
スロー レンダリング フレームとフリーズ フレームは、デバイスのリフレッシュ レートを 60Hz と想定して計算されています。デバイスのリフレッシュ レートが 60 Hz より低い場合、1 秒あたりのレンダリング フレーム数が少なくなるため、各フレームのレンダリング時間が遅くなります。レンダリング時間が遅くなると、より多くのフレームがより遅くレンダリングされるかフリーズするため、より多くの遅いフレームまたはフリーズしたフレームが報告される可能性があります。ただし、デバイスのリフレッシュ レートが 60Hz よりも高い場合、各フレームのレンダリング時間は速くなります。これにより、報告される低速フレームまたはフリーズ フレームが少なくなる可能性があります。これは、Performance Monitoring SDK の現在の制限です。
Firebase Performance Monitoring の BigQuery 統合を有効にしている場合、データは 1 日の終わり (太平洋時間) から 12～24 時間後に BigQuery にエクスポートされます。
たとえば、4 月 19 日のデータは、4 月 20 日の午後 12 時から午前 0 時までの間に BigQuery で利用できるようになります (日付と時刻はすべて太平洋時間です)。
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.
Enable debug logging, as follows:
- In Xcode (minimum v13.3.1), select Product > Scheme > Edit scheme .
- Select Run from the left menu, then select the Arguments tab.
- In the Arguments Passed on Launch section, add
-FIRDebugEnabled.
Check your log messages for any error messages.
Performance Monitoring tags its log messages with
Firebase/Performanceso that you can filter your log messages.Check for the following types of logs which indicate that Performance Monitoring is logging performance events:
-
Logging trace metric: TRACE_NAME , FIREBASE_PERFORMANCE_CONSOLE_URL -
Logging network request trace: URL
-
Click on the URL to view your data in the Firebase console. It may take a few moments for the data to update in the dashboard.
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:
Continue to develop your app using a simulator or test device.
Generate events by switching your app between background and foreground several times, interacting with your app by navigating across screens, and/or triggering network requests.
Make sure that your Firebase configuration file (
Google-Service-Info.plist) is correctly added to your app and that you haven't modified the file. Specifically, check the following:The config file name isn't appended with additional characters, like
(2).The config file is in the root of your XCode project and added to the correct targets.
The Firebase Apple App ID (
GOOGLE_APP_ID) listed in the config file 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 file in your app, try the following:
Delete the config file that you currently have in your app.
Follow these instructions to download a new config file and add it to your Apple app.
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 not disabled through either of the following flags in your
Info.plistfile:-
firebase_performance_collection_enabled -
firebase_performance_collection_deactivated
-
Make sure that Performance Monitoring is not disabled at runtime ( Swift | Obj-C ).
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 not disabled through either of the following flags in your
Info.plistfile:-
firebase_performance_collection_enabled -
firebase_performance_collection_deactivated
-
Make sure that Performance Monitoring is not disabled at runtime ( Swift | Obj-C ).
If you can't find anything that's disabled in your app, contact Firebase Support .
If you're missing data for screen rendering traces, try the following troubleshooting steps:
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.
- Names for custom code traces and custom metrics must meet the following requirements: no leading or trailing whitespace, no leading underscore (
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, try the following troubleshooting steps:
Check for network library incompatibility. Performance Monitoring automatically collects metrics for network requests that use the following networking libraries:
- For Swift: URLSession and URLConnection
- For Objective-C: NSURLSession and NSURLConnection
Note that you can add custom monitoring for network requests .
Be aware of the following:
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.
Performance Monitoring does not report on network requests with invalid
Content-Typeheaders. However, network requests without theContent-Typeheaders will still be accepted.
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 you have enabled the BigQuery integration for Firebase Performance Monitoring, your data will be exported to BigQuery 12 to 24 hours after the end of the day (Pacific Time).
For example, the data for April 19th will be available in BigQuery on April 20th between 12:00pm and midnight (all dates and times are Pacific Time).
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 .