Firebase Performance: co to jest, metryki i jak śledzić

Czym jest Firebase Performance Monitoring

Firebase Performance Monitoring to SDK i platforma chmurowa do zbierania, agregacji i wizualizacji metryk wydajności aplikacji mobilnych. SDK jest osadzane w aplikacji i automatycznie instrumentuje kluczowe punkty: cykl życia Activity (Android) lub ViewController (iOS), zapytania sieciowe przez URLSession (iOS) lub OkHttp (Android) oraz wywołania systemowe. Zebrane dane są wysyłane na serwer Firebase, gdzie są agregowane według wersji aplikacji, urządzeń, krajów i innych atrybutów.

Architektura Performance SDK jest zbudowana na zasadzie minimalnego obciążenia: instrumentacja dodaje nie więcej niż 1–2% do czasu wykonywania mierzonych operacji. Dane są zbierane asynchronicznie i buforowane na urządzeniu przed wysłaniem, co eliminuje wpływ na wydajność wątku UI. Wysyłanie danych odbywa się zgodnie z harmonogramem (domyślnie co 30 minut) lub po osiągnięciu bufora 100 KB.

Kluczowa różnica między Firebase Performance a profilerami Android Studio (CPU Profiler) lub Xcode Instruments to monitorowanie produkcyjne. Firebase Performance zbiera dane z rzeczywistych urządzeń użytkowników, a nie tylko z urządzeń programisty. Pozwala to wykrywać problemy, które występują tylko na określonych modelach, wersjach systemu operacyjnego lub w konkretnych regionach — czyli problemy, których nie można odtworzyć w środowisku kontrolowanym.

Jak SDK zbiera dane bez zmiany kodu

Automatyczna instrumentacja to główna cecha Firebase Performance. Dla Android SDK automatycznie rejestruje ActivityLifecycleCallbacks i mierzy czas między onCreate a onResume (czas renderowania ekranu). Dla iOS — swizzluje metody viewDidLoad i viewDidAppear. Zapytania sieciowe są przechwytywane na poziomie OkHttpInterceptor (Android) lub NSURLProtocol (iOS). Programista nie musi dodawać wywołań start/stop dla standardowych metryk.

Włączanie i wyłączanie Performance SDK jest zarządzane przez Google Services plugin (Android) lub Info.plist (iOS). Do debugowania można włączyć verbose-logowanie Performance SDK, które pokaże, jakie metryki są zbierane i wysyłane. W produkcji zaleca się pozostawienie logowania na poziomie warning, aby nie zaśmiecać logów niepotrzebnymi informacjami. Dla projektów na Flutter lub React Native automatyczna instrumentacja może być ograniczona — więcej w sekcji przykładów kodu.

Bezpłatne limity i taryfikacja

Firebase Performance jest oferowane na bezpłatnym taryfie Spark bez ograniczeń co do liczby śladów lub ilości danych. Płatna taryfa Blaze również nie pobiera opłat za Performance Monitoring — to jedna z niewielu usług Firebase całkowicie bezpłatnych na obu taryfach. Ograniczenie jest tylko jedno: dane są przechowywane 30 dni (na Spark) i do 365 dni (na Blaze). Do długoterminowej analizy eksportuj dane przez BigQuery export.

Brak opłat sprawia, że Firebase Performance jest idealnym wyborem dla każdego projektu — od prototypu po aplikację enterprise z milionami użytkowników. Jedyną pozycją kosztów jest ruch wychodzący danych Performance SDK, ale jest on znikomy w porównaniu z innymi operacjami sieciowymi aplikacji (mniej niż 1 MB miesięcznie na urządzenie). W BigQuery export pobierane są opłaty za przechowywanie i zapytania, ale samo Performance SDK jest bezpłatne.

Automatyczne metryki: co jest mierzone bez kodu

Firebase Performance automatycznie zbiera pięć kategorii metryk bez ani jednej linii kodu: czas uruchamiania aplikacji (app start), wolne zapytania (slow HTTP requests), szybkość renderowania ekranów (screen rendering), zużycie pamięci (memory usage, tylko Android) i częstotliwość klatek (frame rate, tylko Android). Te metryki są dostępne w konsoli Firebase natychmiast po podłączeniu SDK i pierwszej sesji użytkownika.

App Start Time — czas od uruchomienia procesu do pełnej gotowości UI do interakcji. Dzieli się na zimny start (aplikacja uruchamiana od zera) i ciepły start (aplikacja przywracana ze stanu tła). Zimny start obejmuje ładowanie plików DEX, inicjalizację pól statycznych, wywołanie Application.onCreate i Activity.onCreate. Firebase automatycznie klasyfikuje typ startu i pokazuje rozkład czasu dla każdego typu.

Screen Rendering Time — czas od rozpoczęcia ładowania ekranu (onCreate dla Android, viewDidLoad dla iOS) do momentu, gdy ekran jest gotowy do interakcji (onResume, viewDidAppear). Firebase agreguje dane dla każdego ekranu (według nazwy klasy lub custom screen name), pozwalając określić, który ekran ładuje się najdłużej. Dla Android dodatkowo mierzone są dropped frames — liczba klatek pominiętych podczas renderowania ekranu (jank).

Zapytania sieciowe (HTTP/HTTPS)

Performance SDK automatycznie przechwytuje i mierzy każde zapytanie HTTP/HTTPS wysłane z aplikacji przez URLSession, OkHttp lub URLConnection. Dla każdego zapytania rejestrowane są: URL (ścieżka bez parametrów query dla bezpieczeństwa), metoda HTTP, kod odpowiedzi, rozmiar odpowiedzi w bajtach, czas trwania zapytania i prędkość połączenia (WiFi, Cellular). Dane są agregowane w dashboardzie „Network Requests” konsoli Firebase.

Slow Requests — zapytania, których czas trwania przekracza zadany próg. Domyślnie próg „wolnego zapytania” to 4000 ms. Ta metryka jest krytyczna do wykrywania problemów z częścią serwerową: jeśli po aktualizacji backendu liczba slow requests wzrosła z 1% do 15%, to sygnał do natychmiastowej analizy logów serwera. Użytkownicy nie będą czekać na odpowiedź dłużej niż 5 sekund — dane Firebase pokazują, że 53% użytkowników zamyka aplikację, jeśli zapytanie trwa dłużej niż 3 sekundy.

Ograniczenia automatycznej instrumentacji

Ograniczenia iOS: na iOS Performance SDK nie może zmierzyć dropped frames (to prywatne API). Do pomiaru jank na iOS użyj MetricKit lub CADisplayLink. Ponadto na iOS SDK nie przechwytuje zapytań wykonanych przez zewnętrzne klienty HTTP, które nie używają URLSession (na przykład SwiftNIO). W takich przypadkach użyj niestandardowych śladów z atrybutami HTTP.

Ograniczenia Android: na Android automatyczny pomiar pamięci jest dostępny tylko na urządzeniach z Android 8.0+ (API 26+). Dla starszych wersji użyj niestandardowych śladów z pobieraniem danych przez Debug.getMemoryInfo(). SDK nie przechwytuje również połączeń WebSocket — dla nich potrzebne są osobne ślady. Pomimo ograniczeń, automatyczne metryki pokrywają 80% potrzeb monitorowania wydajności.

Niestandardowe ślady i atrybuty HTTP

Niestandardowe ślady (custom traces) to nazwane interwały czasu, które programista tworzy ręcznie do pomiaru wydajności konkretnych scenariuszy: ładowanie listy newsów, przetwarzanie obrazu, synchronizacja danych, wykonywanie złożonego zapytania do bazy danych. Niestandardowe ślady uzupełniają automatyczne metryki i pozwalają mierzyć właśnie te fragmenty kodu, które programista uważa za krytyczne dla wydajności.

Każdy ślad ma nazwę (maksymalnie 100 znaków) i może zawierać do 5 niestandardowych metryk (metrics) — wartości liczbowych, które są zapisywane wewnątrz śladu. Na przykład w śladzie „image_processing” można zmierzyć metryki „original_file_size” i „processed_file_size”. Metryki są wyświetlane w konsoli Firebase jako rozkłady (min, max, average, percentyle), co pozwala analizować nie tylko czas trwania, ale także charakterystykę operacji.

Atrybuty HTTP to specjalny typ niestandardowych śladów dla zapytań sieciowych, które nie zostały automatycznie przechwycone przez SDK (na przykład przez WebSocket lub biblioteki stron trzecich). Atrybuty HTTP obejmują URL, metodę HTTP, kod odpowiedzi i rozmiar odpowiedzi. Firebase wyświetla je w sekcji „Network Requests” razem z automatycznie zebranymi zapytaniami, zapewniając jednolity obraz interakcji sieciowych.

Kiedy używać niestandardowych śladów

Niestandardowe ślady są niezastąpione do pomiaru: czasu ładowania danych z lokalnej bazy danych (Room, CoreData), czasu trwania złożonych obliczeń (szyfrowanie, kompresja), wydajności animacji i przejść, czasu odpowiedzi zewnętrznych SDK (mapy, płatności, analityka). Dla każdego takiego scenariusza utwórz ślad, otocz mierzony kod w start/stop i dodaj atrybuty do późniejszej segmentacji.

Nie nadużywaj niestandardowych śladów. Każdy ślad to dodatkowe zużycie baterii i transferu. Zaleca się nie więcej niż 10–15 aktywnych śladów w wersji produkcyjnej aplikacji. Do debugowania można dodać więcej śladów, ale przed wydaniem wyłącz nadmiarowe przez Remote Config (użyj flagi performance_tracing_enabled). Pozwala to włączyć szczegółowe śledzenie tylko dla wybranych użytkowników lub sesji.

Atrybuty śladów do segmentacji

Niestandardowe atrybuty (custom attributes) to pary klucz-wartość, które można dodać do śladu w celu późniejszego filtrowania w konsoli Firebase. Na przykład do śladu „feed_load” można dodać atrybuty „feed_type” (main, explore, following) i „cache_status” (cold, warm). W konsoli dane śladu można odfiltrować według tych atrybutów, aby określić, który typ listy ładuje się najwolniej.

Ograniczenia: każdy ślad może mieć do 5 niestandardowych atrybutów. Wartość atrybutu to ciąg znaków do 100 znaków. Atrybuty muszą być ustawione przed rozpoczęciem śladu; zmiana atrybutu po rozpoczęciu jest ignorowana. To ograniczenie jest związane z wydajnością: ustalanie atrybutów po starcie wymagałoby dodatkowej synchronizacji.

Progi wydajności i alerty

Progi (thresholds) to konfigurowalne wartości graniczne metryk, po przekroczeniu których Firebase Performance generuje ostrzeżenie. Progi są ustawiane w konsoli Firebase (sekcja Performance > Thresholds) dla każdej automatycznej metryki: app start time (cold/warm), screen rendering time, slow HTTP requests, HTTP response time. Można ustawić globalne progi dla wszystkich wersji aplikacji lub specyficzne dla konkretnych wersji.

Alerty (alerts) to automatyczne powiadomienia, które Firebase wysyła po przekroczeniu progu. Alerty można skonfigurować na email, Slack webhook, PagerDuty lub Cloud Functions (do niestandardowego przetwarzania). Każdy alert zawiera: nazwę metryki, bieżącą wartość, wartość progową, wersję aplikacji, segment (urządzenie, kraj). Alerty pozwalają reagować na degradację wydajności, zanim stanie się zauważalna dla użytkowników.

Zalecane progi według standardu branżowego (Google I/O 2025): zimny start — poniżej 2 sekund, ciepły start — poniżej 1 sekundy, renderowanie ekranu — poniżej 500 ms, czas trwania zapytania HTTP — poniżej 3000 ms (95. percentyl), udział wolnych zapytań — poniżej 5%. Dla aplikacji o wysokiej konkurencyjności (Social, E-commerce) docelowe progi mogą być ostrzejsze: zimny start < 1.5 sekundy, HTTP < 1000 ms.

Konfiguracja progów w konsoli Firebase

W konsoli Firebase przejdź do sekcji Performance, otwórz zakładkę Thresholds. Dla każdej metryki ustaw żądaną wartość progową i procent użytkowników, których ma dotyczyć przekroczenie. Na przykład: „uważamy zimny start za wolny, jeśli przekracza 2 sekundy dla więcej niż 10% użytkowników”. Firebase pokaże bieżące wartości metryk i historię przekroczeń, aby pomóc w wyborze realistycznych progów.

Ważne: progi nie wpływają na zbieranie danych, zarządzają tylko generowaniem powiadomień. Jeśli próg jest zbyt niski (na przykład zimny start 1 sekunda, chociaż 50% urządzeń uruchamia się w 3 sekundy), alerty będą przychodzić ciągle i staną się „szumem”, który programiści przestaną zauważać. Ustawiaj progi na podstawie bieżących wskaźników, a następnie stopniowo je zaostrzaj w miarę optymalizacji aplikacji.

Performance Dashboard w konsoli Firebase

Dashboard Performance wyświetla kluczowe metryki w postaci szeregów czasowych z podziałem według wersji aplikacji, urządzenia, kraju, typu połączenia i wersji systemu operacyjnego. Dla każdej metryki dostępne są: średnia, mediana, 95. percentyl, 99. percentyl. 95. percentyl to najbardziej informacyjna metryka do oceny wydajności, ponieważ pokazuje, jak aplikacja działa na słabych urządzeniach, ignorując wartości odstające.

Dashboard obsługuje porównanie wersji: wybierz dwie wersje aplikacji (bieżącą i poprzednią) do wizualnego porównania metryk. Jeśli po aktualizacji 95. percentyl czasu uruchamiania wzrósł z 2.1 do 3.4 sekundy — regresja jest oczywista i trzeba znaleźć commit, który spowodował spowolnienie. Firebase Performance integruje się z GitHub, GitLab i Bitbucket, co pozwala łączyć zmiany metryk z konkretnymi commitami.

Przykłady kodu dla Performance Monitoring

Rozważmy przykłady integracji Firebase Performance Monitoring w aplikacji Android w Kotlin. Kod demonstruje tworzenie niestandardowego śladu do pomiaru ładowania listy newsów, dodawanie atrybutu HTTP dla nieautomatycznie przechwyconego zapytania oraz użycie Trace do pomiaru czasu przetwarzania obrazu. Wszystkie przykłady uwzględniają możliwość wyłączenia śledzenia przez Remote Config.

Przed użyciem dodaj zależność: implementation("com.google.firebase:firebase-perf") przez Firebase BOM. Do automatycznej instrumentacji nie jest wymagana dodatkowa konfiguracja — SDK przechwytuje standardowe operacje automatycznie po podłączeniu zależności.

Niestandardowy ślad dla ładowania listy

Pierwszy przykład — pomiar czasu ładowania listy newsów z serwera. Ślad otacza asynchroniczną operację fetchFeed, która pobiera dane z sieci i parsuje JSON. Do śladu dodano niestandardowe atrybuty: źródło danych (cache lub network) i liczbę pobranych postów. Pozwala to segmentować dane i zrozumieć, w jakich warunkach lista ładuje się najdłużej.

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

Funkcja loadFeedWithTrace przyjmuje parametr source („cache” lub „network”), który jest używany jako atrybut śladu. Po zakończeniu operacji asynchronicznej ślad jest zatrzymywany w bloku finally, co gwarantuje zatrzymanie nawet przy wyjątku. Metryka items_count pozwala analizować, jak liczba postów wpływa na czas ładowania. W konsoli Firebase można odfiltrować ślady według atrybutu source i zobaczyć, że ładowanie z sieci jest 3 razy wolniejsze niż z pamięci podręcznej.

Atrybut HTTP dla niestandardowego zapytania

Drugi przykład — atrybut HTTP dla zapytania wykonanego przez WebSocket (nieprzechwytywanego automatycznie). Używana jest klasa HttpMetric, która umożliwia ręczne zarejestrowanie zapytania URL, jego metody, kodu odpowiedzi i rozmiaru. Firebase wyświetli to zapytanie w sekcji Network Requests razem z automatycznie przechwyconymi.

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

W przykładzie sendWithHttpMetric używa newHttpMetric do rejestracji niestandardowego wywołania HTTP. SDK nie przechwytuje go automatycznie, dlatego programista ręcznie ustawia URL, metodę, kod odpowiedzi i rozmiary. Ważne jest ustawienie URL bez parametrów query (dla bezpieczeństwa i agregacji) — czyli /data, a nie /data?token=abc. Firebase automatycznie grupuje podobne wzorce URL.

Pomiar czasu przetwarzania obrazu

Trzeci przykład demonstruje pomiar czasu przetwarzania obrazu (kompresja, zmiana rozmiaru) za pomocą niestandardowego śladu. W tym przypadku ślad otacza operację synchroniczną, ale do produkcji użyj korutyn lub RxJava, aby nie blokować wątku 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
}

Funkcja compressImage mierzy czas kompresji obrazu do JPEG z jakością 80%. Atrybut format pozwala w przyszłości porównywać czas kompresji JPEG vs WebP. Metryka output_size_kb pokazuje, jak efektywna jest kompresja. W konsoli Firebase można zobaczyć rozkład: na słabych urządzeniach (budżetowe Android) kompresja zajmuje 4 razy więcej czasu niż na flagowcach, co może być przyczyną opóźnień przy wysyłaniu obrazów na serwer.

Jak poprawiać wydajność na podstawie danych

Firebase Performance dostarcza dane, ale nie daje gotowych rozwiązań. Analiza metryk wymaga zrozumienia typowych przyczyn degradacji wydajności dla każdej metryki. Rozważmy główne wzorce pogorszenia i sposoby ich diagnozowania na podstawie danych Performance Monitoring. Podejście: znajdź anomalię w metryce → sprawdź typowe przyczyny → zastosuj optymalizację → sprawdź wynik za tydzień.

Wolny zimny start (> 2 sekund): przyczyny — ciężka inicjalizacja SDK w Application.onCreate (analityka, crash reporting, map SDK), ładowanie dużych zasobów (czcionki, motywy), operacje synchroniczne w głównym wątku podczas uruchamiania. Rozwiązania: leniwa inicjalizacja SDK, opóźnione ładowanie zasobów, użycie SplashScreen API (Android 12+) do wyświetlenia placeholder podczas inicjalizacji. Firebase Performance pokaże, która wersja aplikacji zaczęła uruchamiać się wolniej — sprawdź, jakie zależności zostały dodane lub zaktualizowane.

Wolne renderowanie ekranu (> 500 ms): przyczyny — złożona hierarchia View (zagnieżdżone ConstraintLayout, wiele Fragment), ładowanie danych w wątku UI (sieć lub dysk), ciężkie operacje draw (duże obrazy, niestandardowe View). Rozwiązania: optymalizacja hierarchii layout (Layout Inspector w Android Studio), przeniesienie danych do wątku tła, buforowanie obrazów przez Glide lub Coil. Użyj filtru Screen Rendering w Firebase, aby znaleźć najwolniejszy ekran i zoptymalizować go w pierwszej kolejności.

Optymalizacja zapytań sieciowych

Wolne zapytania HTTP (> 3 sekund): przyczyny — wolny serwer, duże payloady, brak buforowania, nieoptymalny protokół (HTTP/1.1 zamiast HTTP/2), rozwiązywanie DNS. Rozwiązania: sprawdź stronę serwerową (uptime, latency), zmniejsz rozmiar odpowiedzi (paginacja, GraphQL, protobuf zamiast JSON), włącz buforowanie przez nagłówki HTTP (Cache-Control), użyj OkHttp Interceptor do dodania timeoutów i logiki ponawiania.

Firebase Performance pokazuje rozkład czasu zapytania: DNS resolution, TCP handshake, TLS handshake, request send, response receive. Jeśli większość czasu przypada na DNS — użyj wstępnego ładowania DNS (OkHttp DNS-over-HTTPS). Jeśli na TLS — użyj session resumption i dostrojenia cipher suites. Jeśli na response receive — sprawdź rozmiar odpowiedzi i prędkość sieci użytkownika. Dane Firebase pozwalają zlokalizować problem na poziomie protokołu, a nie tylko stwierdzić „zapytanie jest wolne”.

Integracja Remote Config do wyłączania śledzenia

Do produkcji zaleca się dodanie flagi Remote Config performance_tracing_enabled, która umożliwia zdalne wyłączanie niestandardowych śladów. Jeśli Firebase Performance SDK na kliencie generuje zbyt dużo danych lub wpływa na wydajność (na słabych urządzeniach), można wyłączyć ślady dla wszystkich użytkowników, pozostawiając tylko automatyczne metryki, które mają minimalne obciążenie.

Przykład logiki: podczas uruchamiania aplikacji sprawdzamy parametr Remote Config performance_tracing_enabled. Jeśli false — wszystkie wywołania Firebase.performance.newTrace() zwracają obiekt stub, który nie zbiera danych. Jest to realizowane przez klasę wrapper, która sprawdza flagę przed utworzeniem śladu. Takie podejście pozwala włączyć szczegółowe śledzenie dla konkretnych użytkowników (beta testerów, programistów) bez wpływu na całą publiczność.