Firebase Performance: 概要、メトリクス、追跡方法

Firebase Performance Monitoringとは

Firebase Performance Monitoringは、モバイルアプリのパフォーマンスメトリクスを収集、集約、可視化するSDKおよびクラウドプラットフォームです。SDKはアプリに組み込まれ、Activityのライフサイクル（Android）やViewController（iOS）、URLSession（iOS）やOkHttp（Android）を介したネットワークリクエスト、システムコールなどの主要ポイントを自動的にインストルメント化します。収集されたデータはFirebaseサーバーに送信され、アプリバージョン、デバイス、国、その他の属性ごとに集約されます。

Performance SDKのアーキテクチャは最小限のオーバーヘッドの原則に基づいています。インストルメント化によって測定対象の操作の実行時間に追加されるのは1～2%以下です。データは非同期で収集され、送信前にデバイス上でバッファリングされるため、UIスレッドのパフォーマンスへの影響はありません。データはスケジュールに従って（デフォルトでは30分ごと）またはバッファが100KBに達したときに送信されます。

Firebase PerformanceとAndroid Studioプロファイラ（CPU Profiler）やXcode Instrumentsとの主な違いは、本番環境でのモニタリングです。Firebase Performanceは開発者デバイスだけでなく、実際のユーザーデバイスからデータを収集します。これにより、特定のモデル、OSバージョン、特定の地域でのみ発生する問題——管理された環境では再現できない問題——を検出できます。

コード変更なしでSDKがデータを収集する仕組み

自動インストルメント化がFirebase Performanceの主要機能です。Androidの場合、SDKは自動的にActivityLifecycleCallbacksを登録し、onCreateからonResumeまでの時間（画面レンダリング時間）を測定します。iOSの場合は、viewDidLoadとviewDidAppearメソッドをスウィズルします。ネットワークリクエストはOkHttpInterceptor（Android）またはNSURLProtocol（iOS）レベルでインターセプトされます。開発者は標準メトリクスのためにstart/stop呼び出しを追加する必要はありません。

Performance SDKの有効化と無効化は、Google Servicesプラグイン（Android）またはInfo.plist（iOS）を介して管理されます。デバッグ時には、Performance SDKの詳細ログを有効にして、どのメトリクスが収集・送信されているかを確認できます。本番環境では、不要な情報でログが散らかるのを防ぐため、ログレベルを警告に保つことを推奨します。FlutterやReact Nativeのプロジェクトでは、自動インストルメント化が制限される場合があります。詳細はコード例のセクションを参照してください。

無料枠と料金

Firebase Performanceは、無料のSpark枠でトレース数やデータ量に制限なく利用できます。有料のBlaze枠でもPerformance Monitoringの料金は発生しません——両方の枠で完全に無料の数少ないFirebaseサービスの1つです。制限は1つだけです。データの保存期間は30日間（Spark）および最大365日間（Blaze）です。長期分析の場合は、BigQueryエクスポートを介してデータをエクスポートしてください。

無料であることにより、Firebase Performanceはプロトタイプから数百万ユーザーのエンタープライズアプリケーションまで、あらゆるプロジェクトに最適な選択肢となります。唯一の費用はPerformance SDKの送信トラフィックですが、アプリの他のネットワーク操作と比較するとごくわずかです（デバイスあたり月1MB未満）。BigQueryエクスポートではストレージとクエリに料金がかかりますが、Performance SDK自体は無料です。

自動メトリクス: コードなしで測定されるもの

Firebase Performanceは、コードを1行も書かずに5つのカテゴリのメトリクスを自動収集します。アプリの起動時間、低速HTTPリクエスト、画面レンダリング速度、メモリ使用量（Androidのみ）、フレームレート（Androidのみ）です。これらのメトリクスは、SDKを接続して最初のユーザーセッションが行われた直後にFirebaseコンソールで利用可能になります。

アプリ起動時間——プロセス起動からUIが完全に操作可能になるまでの時間です。コールドスタート（アプリがゼロから起動）とウォームスタート（アプリがバックグラウンド状態から再開）に分類されます。コールドスタートには、DEXファイルの読み込み、静的フィールドの初期化、Application.onCreateとActivity.onCreateの呼び出しが含まれます。Firebaseは自動的に起動タイプを分類し、各タイプの時間分布を表示します。

画面レンダリング時間——画面の読み込み開始（Androidの場合はonCreate、iOSの場合はviewDidLoad）から画面が操作可能になる瞬間（onResume、viewDidAppear）までの時間です。Firebaseは各画面（クラス名またはカスタム画面名）ごとにデータを集約し、どの画面の読み込みに最も時間がかかるかを特定できます。Androidでは、画面レンダリング中にスキップされたフレーム数（ジャンク）であるドロップフレームも測定されます。

ネットワークリクエスト（HTTP/HTTPS）

Performance SDKは、URLSession、OkHttp、URLConnectionを介してアプリから送信されるすべてのHTTP/HTTPSリクエストを自動的にインターセプトして測定します。各リクエストについて、URL（セキュリティのためクエリパラメータを除いたパス）、HTTPメソッド、レスポンスコード、レスポンスサイズ（バイト）、リクエスト所要時間、接続速度（WiFi、携帯電話）が記録されます。データはFirebaseコンソールのネットワークリクエストダッシュボードに集約されます。

低速リクエスト——所要時間が設定されたしきい値を超えるリクエストです。デフォルトの低速リクエストしきい値は4000msです。このメトリクスはバックエンドの問題を特定する上で重要です。バックエンドのアップデート後に低速リクエストの数が1%から15%に増加した場合、それは直ちにサーバーログを分析する必要があるシグナルです。ユーザーはレスポンスに5秒以上待つことはありません——Firebaseのデータによると、リクエストに3秒以上かかると53%のユーザーがアプリを閉じることが示されています。

自動インストルメント化の制限

iOSの制限：iOSでは、Performance SDKはドロップフレームを測定できません（これはプライベートAPIです）。iOSでジャンクを測定するには、MetricKitまたはCADisplayLinkを使用してください。また、iOSでは、SDKはURLSessionを使用しないサードパーティのHTTPクライアント（SwiftNIOなど）を介して実行されたリクエストをインターセプトしません。そのような場合は、HTTP属性を持つカスタムトレースを使用してください。

Androidの制限：Androidでは、自動メモリ測定はAndroid 8.0+（API 26+）のデバイスでのみ利用可能です。古いバージョンの場合は、Debug.getMemoryInfo()を介して取得したデータを使用したカスタムトレースを使用してください。また、SDKはWebSocket接続をインターセプトしません——これらには個別のトレースが必要です。これらの制限にもかかわらず、自動メトリクスはパフォーマンス監視のニーズの80%をカバーします。

カスタムトレースとHTTP属性

カスタムトレースは、開発者が特定のシナリオ（ニュースフィードの読み込み、画像処理、データ同期、複雑なデータベースクエリの実行）のパフォーマンスを測定するために手動で作成する名前付きの時間間隔です。カスタムトレースは自動メトリクスを補完し、開発者がパフォーマンス上重要と考えるコードセグメントを正確に測定できます。

各トレースには名前（最大100文字）があり、最大5つのカスタムメトリクス（トレース内に記録される数値）を含めることができます。たとえば、「image_processing」トレースでは、「original_file_size」や「processed_file_size」などのメトリクスを測定できます。メトリクスはFirebaseコンソールに分布（最小、最大、平均、パーセンタイル）として表示され、所要時間だけでなく操作の特性も分析できます。

HTTP属性——SDKによって自動的にインターセプトされなかったネットワークリクエスト（WebSocketやサードパーティライブラリ経由など）のための特別なタイプのカスタムトレースです。HTTP属性には、URL、HTTPメソッド、レスポンスコード、レスポンスサイズが含まれます。Firebaseはこれらを自動収集されたリクエストと一緒にネットワークリクエストセクションに表示し、ネットワークインタラクションの統一的な全体像を提供します。

カスタムトレースを使用すべき場合

カスタムトレースは、ローカルデータベース（Room、CoreData）からのデータ読み込み時間、複雑な計算（暗号化、圧縮）の所要時間、アニメーションや画面遷移のパフォーマンス、サードパーティSDK（マップ、決済、分析）の応答時間を測定するために不可欠です。このようなシナリオごとにトレースを作成し、測定対象のコードをstart/stopでラップし、後続のセグメンテーション用に属性を追加してください。

カスタムトレースを使いすぎないでください。各トレースはバッテリーとトラフィックのオーバーヘッドを追加します。本番バージョンのアプリでは、アクティブなトレースは10～15個以下にすることを推奨します。デバッグ時にはさらに多くのトレースを追加できますが、リリース前にはRemote Config（performance_tracing_enabledフラグを使用）を介して過剰なトレースを無効にしてください。これにより、選択したユーザーやセッションにのみ詳細なトレースを有効にできます。

セグメンテーションのためのトレース属性

カスタム属性は、Firebaseコンソールで後からフィルタリングするためにトレースに追加できるキーと値のペアです。たとえば、「feed_load」トレースには、「feed_type」（main、explore、following）や「cache_status」（cold、warm）などの属性を追加できます。コンソールでは、これらの属性でトレースデータをフィルタリングして、どのフィードタイプが最も遅く読み込まれるかを判断できます。

制限：各トレースには最大5つのカスタム属性を含めることができます。属性値は最大100文字の文字列です。属性はトレースの開始前に設定する必要があります。開始後の属性変更は無視されます。この制限はパフォーマンスに関連しています——開始後に属性を固定するには追加の同期が必要になります。

パフォーマンスしきい値とアラート

しきい値は、メトリクスの設定可能な境界値で、超過するとFirebase Performanceが警告を生成します。しきい値はFirebaseコンソール（Performance > Thresholds）で各自動メトリクス（アプリ起動時間（コールド/ウォーム）、画面レンダリング時間、低速HTTPリクエスト、HTTP応答時間）に対して設定できます。すべてのアプリバージョンにグローバルなしきい値を設定することも、特定のバージョンに固有のしきい値を設定することもできます。

アラートは、しきい値を超えたときにFirebaseが送信する自動通知です。アラートはメール、Slack webhook、PagerDuty、Cloud Functions（カスタム処理用）を介して設定できます。各アラートには、メトリクス名、現在値、しきい値、アプリバージョン、セグメント（デバイス、国）が含まれます。アラートにより、ユーザーが気付く前にパフォーマンス低下に対応できます。

推奨しきい値（業界標準、Google I/O 2025による）：コールドスタート——2秒未満、ウォームスタート——1秒未満、画面レンダリング——500ms未満、HTTPリクエスト所要時間——3000ms未満（95パーセンタイル）、低速リクエストの割合——5%未満。競争の激しいアプリ（ソーシャル、Eコマース）の場合、目標しきい値はさらに厳しくすることができます：コールドスタート1.5秒未満、HTTP1000ms未満。

Firebaseコンソールでのしきい値設定

Firebaseコンソールで、Performanceセクションに移動し、Thresholdsタブを開きます。各メトリクスについて、希望するしきい値と、超過の影響を受けるユーザーの割合を設定します。例：「10%以上のユーザーで2秒を超える場合、コールドスタートを低速とみなす」。Firebaseは現在のメトリクス値と超過履歴を表示し、現実的なしきい値の選択を支援します。

重要：しきい値はデータ収集には影響せず、通知の生成のみを制御します。しきい値が低すぎる場合（たとえば、50%のデバイスが3秒で起動するのにコールドスタート1秒）、アラートが常に届き、開発者が気にしなくなる「ノイズ」になります。現在のパフォーマンスに基づいてしきい値を設定し、アプリの最適化に伴って徐々に厳しくしてください。

Firebaseコンソールのパフォーマンスダッシュボード

パフォーマンスダッシュボードは、主要メトリクスをアプリバージョン、デバイス、国、接続タイプ、OSバージョンで分類した時系列として表示します。各メトリクスについて、平均、中央値、95パーセンタイル、99パーセンタイルが利用可能です。95パーセンタイルは、外れ値を無視して弱いデバイスでのアプリのパフォーマンスを示すため、パフォーマンス評価において最も情報量の多いメトリクスです。

ダッシュボードはバージョン比較をサポートしています。メトリクスを視覚的に比較するために、2つのアプリバージョン（現在と以前）を選択します。アップデート後に95パーセンタイルの起動時間が2.1秒から3.4秒に増加した場合——回帰は明らかで、どのコミットが遅延を引き起こしたかを見つける必要があります。Firebase PerformanceはGitHub、GitLab、Bitbucketと統合されており、メトリクスの変更を特定のコミットにリンクできます。

Performance Monitoringのコード例

Kotlinを使用したAndroidアプリでのFirebase Performance Monitoringの統合例を見てみましょう。コードは、ニュースフィードの読み込みを測定するカスタムトレースの作成、自動インターセプトされないリクエストのHTTP属性の追加、Traceを使用した画像処理時間の測定を示しています。すべての例は、Remote Configを介してトレースを無効にする機能を考慮しています。

使用前に、Firebase BOMを介して依存関係を追加します：implementation("com.google.firebase:firebase-perf")。自動インストルメント化には追加の設定は不要です——依存関係を追加すると、SDKが自動的に標準操作をインターセプトします。

フィード読み込みのカスタムトレース

最初の例は、サーバーからのニュースフィードの読み込み時間の測定です。トレースは、ネットワークからデータを取得してJSONをパースする非同期のfetchFeed操作をラップします。トレースには、データソース（cacheまたはnetwork）と受信した投稿数というカスタム属性が追加されています。これにより、データをセグメント化して、どの条件下でフィードが最も遅く読み込まれるかを理解できます。

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

関数loadFeedWithTraceは、トレース属性として使用されるsourceパラメータ（"cache"または"network"）を受け取ります。非同期操作が完了すると、トレースはfinallyブロックで停止し、例外が発生した場合でも停止を保証します。items_countメトリクスは、投稿数が読み込み時間にどのように影響するかを分析できます。Firebaseコンソールで、source属性でトレースをフィルタリングすると、ネットワーク読み込みがキャッシュより3倍遅いことがわかります。

非標準リクエストのHTTP属性

2番目の例は、WebSocketを介して実行されたリクエスト（自動インターセプトされない）のHTTP属性です。HttpMetricクラスを使用して、URLリクエスト、そのメソッド、レスポンスコード、サイズを手動で登録できます。Firebaseはこのリクエストを、自動インターセプトされたリクエストと一緒にネットワークリクエストセクションに表示します。

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

例では、sendWithHttpMetricがnewHttpMetricを使用して非標準のHTTP呼び出しを登録します。SDKは自動的にインターセプトしないため、開発者が手動でURL、メソッド、レスポンスコード、サイズを設定します。URLはクエリパラメータなしで設定することが重要です（セキュリティと集約のため）——つまり/data?token=abcではなく/dataとします。Firebaseは自動的に同一のURLパターンをグループ化します。

画像処理時間の測定

3番目の例は、カスタムトレースを使用した画像処理（圧縮、リサイズ）の時間測定を示しています。この場合、トレースは同期操作をラップしていますが、本番環境ではUIスレッドをブロックしないようにコルーチンやRxJavaを使用してください。

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
}

関数compressImageは、品質80%でのJPEG画像圧縮時間を測定します。format属性により、将来JPEGとWebPの圧縮時間を比較できます。output_size_kbメトリクスは圧縮の効率を示します。Firebaseコンソールでは、分布を確認できます。弱いデバイス（低価格Android）では、圧縮にフラッグシップモデルの4倍の時間がかかり、サーバーへの画像アップロード時の遅延の原因になる可能性があります。

データに基づくパフォーマンス改善方法

Firebase Performanceはデータを提供しますが、既成の解決策を提供するわけではありません。メトリクスの分析には、各メトリクスのパフォーマンス低下の典型的な原因を理解する必要があります。主要な低下パターンと、Performance Monitoringのデータを使用した診断方法を見てみましょう。アプローチ：メトリクスの異常を見つける→典型的な原因を確認する→最適化を適用する→1週間後に結果を確認する。

低速なコールドスタート（2秒超）：原因——Application.onCreateでの重いSDK初期化（分析、クラッシュレポート、マップSDK）、大きなリソースの読み込み（フォント、テーマ）、起動時のメインスレッドでの同期操作。解決策：遅延SDK初期化、遅延リソース読み込み、初期化中にプレースホルダーを表示するSplashScreen API（Android 12+）の使用。Firebase Performanceはどのアプリバージョンが遅くなり始めたかを示します——どの依存関係が追加または更新されたかを確認してください。

低速な画面レンダリング（500ms超）：原因——複雑なView階層（ネストされたConstraintLayout、複数のFragment）、UIスレッドでのデータ読み込み（ネットワークまたはディスク）、重い描画操作（大きな画像、カスタムView）。解決策：レイアウト階層の最適化（Android StudioのLayout Inspector）、データのバックグラウンドスレッドへのオフロード、GlideやCoilによる画像キャッシュ。Firebaseの画面レンダリングフィルターを使用して最も遅い画面を見つけ、最初に最適化します。

ネットワークリクエストの最適化

低速HTTPリクエスト（3秒超）：原因——低速サーバー、大きなペイロード、キャッシュの欠如、最適でないプロトコル（HTTP/2ではなくHTTP/1.1）、DNS解決。解決策：サーバー側を確認（アップタイム、レイテンシ）、レスポンスサイズを削減（ページネーション、GraphQL、JSONの代わりにprotobuf）、HTTPヘッダー（Cache-Control）によるキャッシュを有効化、OkHttp Interceptorを使用してタイムアウトとリトライロジックを追加。

Firebase Performanceはリクエストの時間分布を表示します：DNS解決、TCPハンドシェイク、TLSハンドシェイク、リクエスト送信、レスポンス受信。時間の大部分がDNSに費やされている場合——DNSプリロード（OkHttp DNS-over-HTTPS）を使用します。TLSの場合——セッション再開と暗号スイートのチューニングを使用します。レスポンス受信の場合——レスポンスサイズとユーザーのネットワーク速度を確認します。Firebaseのデータにより、「リクエストが遅い」と言うだけでなく、プロトコルレベルで問題を特定できます。

トレース無効化のためのRemote Config統合

本番環境では、Remote Configフラグperformance_tracing_enabledを追加することを推奨します。これにより、カスタムトレースをリモートで無効にできます。クライアント側のFirebase Performance SDKが大量のデータを生成したり、パフォーマンスに影響を与えたりする場合（弱いデバイスで）、すべてのユーザーのトレースを無効にし、最小限のオーバーヘッドしかない自動メトリクスのみを残すことができます。

ロジック例：アプリ起動時にRemote Configパラメータperformance_tracing_enabledを確認します。falseの場合——Firebase.performance.newTrace()へのすべての呼び出しは、データを収集しないスタブオブジェクトを返します。これは、トレース作成前にフラグを確認するラッパークラスを介して実装されます。このアプローチにより、全ユーザーに影響を与えることなく、特定のユーザー（ベータテスター、開発者）に対して詳細なトレースを有効にできます。