Firebase Performance: co to je, metriky a jak sledovat

Co je Firebase Performance Monitoring

Firebase Performance Monitoring je SDK a cloudová platforma pro sběr, agregaci a vizualizaci metrik výkonu mobilních aplikací. SDK je vloženo do aplikace a automaticky instrumentuje klíčové body: životní cyklus Activity (Android) nebo ViewController (iOS), síťové požadavky přes URLSession (iOS) nebo OkHttp (Android) a systémová volání. Shromážděná data jsou odeslána na server Firebase, kde jsou agregována podle verzí aplikace, zařízení, zemí a dalších atributů.

Architektura Performance SDK je postavena na principu minimální režie: instrumentace přidává ne více než 1–2 % k času provádění měřených operací. Data jsou shromažďována asynchronně a ukládána do vyrovnávací paměti na zařízení před odesláním, což eliminuje dopad na výkon vlákna UI. Odesílání dat probíhá podle plánu (ve výchozím nastavení každých 30 minut) nebo po dosažení vyrovnávací paměti 100 KB.

Klíčový rozdíl mezi Firebase Performance a profilerovacími nástroji Android Studio (CPU Profiler) nebo Xcode Instruments je monitorování v produkci. Firebase Performance shromažďuje data ze skutečných zařízení uživatelů, nejen z vývojářských zařízení. To umožňuje detekovat problémy, které se vyskytují pouze na určitých modelech, verzích OS nebo v konkrétních regionech — tedy problémy, které nelze reprodukovat v kontrolovaném prostředí.

Jak SDK shromažďuje data bez změny kódu

Automatická instrumentace je hlavní vlastností Firebase Performance. Pro Android SDK automaticky registruje ActivityLifecycleCallbacks a měří čas mezi onCreate a onResume (čas vykreslování obrazovky). Pro iOS — swizzluje metody viewDidLoad a viewDidAppear. Síťové požadavky jsou zachyceny na úrovni OkHttpInterceptor (Android) nebo NSURLProtocol (iOS). Vývojář nemusí přidávat volání start/stop pro standardní metriky.

Povolení a zakázání Performance SDK je spravováno přes plugin Google Services (Android) nebo Info.plist (iOS). Pro ladění lze povolit podrobné protokolování Performance SDK, které ukáže, které metriky jsou shromažďovány a odesílány. V produkci se doporučuje ponechat protokolování na úrovni warning, aby se nezaplňovaly protokoly zbytečnými informacemi. U projektů na Flutter nebo React Native může být automatická instrumentace omezena — více podrobností v sekci příkladů kódu.

Bezplatné limity a ceník

Firebase Performance je nabízeno v bezplatném tarifu Spark bez omezení počtu trasování nebo objemu dat. Placený tarif Blaze také neúčtuje poplatky za Performance Monitoring — to je jedna z mála služeb Firebase zcela zdarma v obou tarifech. Existuje pouze jedno omezení: data jsou uchovávána po dobu 30 dnů (na Spark) a až 365 dnů (na Blaze). Pro dlouhodobou analýzu exportujte data pomocí BigQuery export.

Bezplatnost činí Firebase Performance ideální volbou pro jakýkoli projekt — od prototypu až po podnikovou aplikaci s miliony uživatelů. Jedinou nákladovou položkou je odchozí provoz dat Performance SDK, ale ten je zanedbatelný ve srovnání s jinými síťovými operacemi aplikace (méně než 1 MB měsíčně na zařízení). V BigQuery exportu jsou účtovány poplatky za ukládání a dotazy, ale samotné Performance SDK je zdarma.

Automatické metriky: co se měří bez kódu

Firebase Performance automaticky shromažďuje pět kategorií metrik bez jediného řádku kódu: dobu spouštění aplikace (app start), pomalé požadavky (slow HTTP requests), rychlost vykreslování obrazovek (screen rendering), využití paměti (memory usage, pouze Android) a snímkovou frekvenci (frame rate, pouze Android). Tyto metriky jsou v konzoli Firebase k dispozici ihned po připojení SDK a první relaci uživatele.

App Start Time — čas od spuštění procesu do úplné připravenosti UI k interakci. Dělí se na studený start (aplikace startuje od nuly) a teplý start (aplikace se obnovuje z pozadí). Studený start zahrnuje načítání DEX souborů, inicializaci statických polí, volání Application.onCreate a Activity.onCreate. Firebase automaticky klasifikuje typ startu a zobrazuje rozdělení času pro každý typ.

Screen Rendering Time — čas od začátku načítání obrazovky (onCreate pro Android, viewDidLoad pro iOS) do okamžiku, kdy je obrazovka připravena k interakci (onResume, viewDidAppear). Firebase agreguje data pro každou obrazovku (podle názvu třídy nebo vlastního názvu obrazovky), což umožňuje určit, která obrazovka se načítá nejdéle. Pro Android se navíc měří vynechané snímky (dropped frames) — počet snímků zmeškaných při vykreslování obrazovky (jank).

Síťové požadavky (HTTP/HTTPS)

Performance SDK automaticky zachycuje a měří každý HTTP/HTTPS požadavek odeslaný z aplikace přes URLSession, OkHttp nebo URLConnection. Pro každý požadavek jsou zaznamenány: URL (cesta bez parametrů dotazu pro bezpečnost), HTTP metoda, kód odpovědi, velikost odpovědi v bajtech, doba trvání požadavku a rychlost připojení (WiFi, Cellular). Data jsou agregována v dashboardu „Network Requests” konzole Firebase.

Slow Requests — požadavky, jejichž doba trvání překračuje stanovenou prahovou hodnotu. Výchozí prahová hodnota „pomalého požadavku” je 4000 ms. Tato metrika je kritická pro identifikaci problémů se serverovou stranou: pokud se po aktualizaci backendu zvýšil počet pomalých požadavků z 1 % na 15 %, je to signál pro okamžitou analýzu serverových protokolů. Uživatelé nebudou čekat na odpověď déle než 5 sekund — data Firebase ukazují, že 53 % uživatelů zavře aplikaci, pokud požadavek trvá déle než 3 sekundy.

Omezení automatické instrumentace

Omezení iOS: na iOS nemůže Performance SDK měřit vynechané snímky (jedná se o soukromé API). Pro měření jank na iOS použijte MetricKit nebo CADisplayLink. Na iOS SDK také nezachycuje požadavky provedené prostřednictvím HTTP klientů třetích stran, které nepoužívají URLSession (například SwiftNIO). Pro takové případy použijte vlastní trasování s HTTP atributy.

Omezení Android: na Androidu je automatické měření paměti dostupné pouze na zařízeních s Android 8.0+ (API 26+). Pro starší verze použijte vlastní trasování se získáním dat přes Debug.getMemoryInfo(). SDK také nezachycuje WebSocket připojení — pro ně jsou potřeba samostatná trasování. Navzdory omezením pokrývají automatické metriky 80 % potřeb monitorování výkonu.

Vlastní trasování a HTTP atributy

Vlastní trasování (custom traces) jsou pojmenované časové intervaly, které vývojář vytváří ručně pro měření výkonu konkrétních scénářů: načítání zpravodajského feedu, zpracování obrázku, synchronizace dat, provádění složitého databázového dotazu. Vlastní trasování doplňují automatické metriky a umožňují měřit přesně ty části kódu, které vývojář považuje za kritické pro výkon.

Každé trasování má název (maximálně 100 znaků) a může obsahovat až 5 vlastních metrik — číselných hodnot, které jsou zaznamenány uvnitř trasování. Například v trasování „image_processing” lze měřit metriky „original_file_size” a „processed_file_size”. Metriky jsou v konzoli Firebase zobrazeny jako rozdělení (min, max, average, percentily), což umožňuje analyzovat nejen dobu trvání, ale také charakteristiky operace.

HTTP atributy jsou speciálním typem vlastního trasování pro síťové požadavky, které nebyly automaticky zachyceny SDK (například přes WebSocket nebo knihovny třetích stran). HTTP atributy zahrnují URL, HTTP metodu, kód odpovědi a velikost odpovědi. Firebase je zobrazuje v sekci „Network Requests” spolu s automaticky shromážděnými požadavky, což poskytuje jednotný obraz síťové interakce.

Kdy použít vlastní trasování

Vlastní trasování jsou nepostradatelná pro měření: doby načítání dat z lokální databáze (Room, CoreData), doby trvání složitých výpočtů (šifrování, komprese), výkonu animací a přechodů, doby odezvy SDK třetích stran (mapy, platby, analytika). Pro každý takový scénář vytvořte trasování, obalte měřený kód do start/stop a přidejte atributy pro pozdější segmentaci.

Nezneužívejte vlastní trasování. Každé trasování znamená dodatečnou spotřebu baterie a dat. Doporučuje se nejvýše 10–15 aktivních trasování v produkční verzi aplikace. Pro ladění lze přidat více trasování, ale před vydáním vypněte nadbytečná pomocí Remote Config (použijte příznak performance_tracing_enabled). To umožňuje podrobné sledování pouze pro vybrané uživatele nebo relace.

Atributy trasování pro segmentaci

Vlastní atributy (custom attributes) jsou páry klíč-hodnota, které lze přidat k trasování pro pozdější filtrování v konzoli Firebase. Například k trasování „feed_load” lze přidat atributy „feed_type” (main, explore, following) a „cache_status” (cold, warm). V konzoli lze data trasování filtrovat podle těchto atributů a určit, který typ feedu se načítá nejpomaleji.

Omezení: každé trasování může mít až 5 vlastních atributů. Hodnota atributu je řetězec o délce až 100 znaků. Atributy musí být nastaveny před zahájením trasování; změna atributu po zahájení je ignorována. Toto omezení souvisí s výkonem: nastavení atributů po zahájení by vyžadovalo dodatečnou synchronizaci.

Prahové hodnoty výkonu a upozornění

Prahové hodnoty (thresholds) jsou konfigurovatelné hraniční hodnoty metrik, při jejichž překročení Firebase Performance generuje upozornění. Prahové hodnoty se nastavují v konzoli Firebase (sekce Performance > Thresholds) pro každou automatickou metriku: app start time (cold/warm), screen rendering time, slow HTTP requests, HTTP response time. Lze nastavit globální prahové hodnoty pro všechny verze aplikace nebo specifické pro konkrétní verze.

Upozornění (alerts) jsou automatická oznámení, která Firebase odesílá při překročení prahové hodnoty. Upozornění lze nakonfigurovat pro email, Slack webhook, PagerDuty nebo Cloud Functions (pro vlastní zpracování). Každé upozornění obsahuje: název metriky, aktuální hodnotu, prahovou hodnotu, verzi aplikace, segment (zařízení, země). Upozornění umožňují reagovat na degradaci výkonu dříve, než si jí uživatelé všimnou.

Doporučené prahové hodnoty podle průmyslového standardu (Google I/O 2025): studený start — méně než 2 sekundy, teplý start — méně než 1 sekunda, vykreslování obrazovky — méně než 500 ms, doba trvání HTTP požadavku — méně než 3000 ms (95. percentil), podíl pomalých požadavků — méně než 5 %. U aplikací s vysokou konkurencí (Social, E-commerce) mohou být cílové prahové hodnoty přísnější: studený start < 1,5 sekundy, HTTP < 1000 ms.

Nastavení prahových hodnot v konzoli Firebase

V konzoli Firebase přejděte do sekce Performance, otevřete kartu Thresholds. Pro každou metriku nastavte požadovanou prahovou hodnotu a procento uživatelů, kterých se má překročení týkat. Například: „považujeme studený start za pomalý, pokud přesahuje 2 sekundy u více než 10 % uživatelů”. Firebase zobrazí aktuální hodnoty metrik a historii překročení, aby pomohl při výběru realistických prahových hodnot.

Důležité: prahové hodnoty neovlivňují sběr dat, pouze řídí generování oznámení. Pokud je prahová hodnota příliš nízká (například studený start 1 sekunda, přestože 50 % zařízení startuje za 3 sekundy), upozornění budou chodit neustále a stanou se „šumem”, kterého si vývojáři přestanou všímat. Nastavujte prahové hodnoty na základě aktuálních ukazatelů a poté je postupně zpřísňujte, jak aplikaci optimalizujete.

Dashboard Performance v konzoli Firebase

Dashboard Performance zobrazuje klíčové metriky jako časové řady s rozpisem podle verze aplikace, zařízení, země, typu připojení a verze OS. Pro každou metriku jsou k dispozici: průměr, medián, 95. percentil, 99. percentil. 95. percentil je nejinformativnější metrikou pro hodnocení výkonu, protože ukazuje, jak aplikace pracuje na „slabých zařízeních”, přičemž ignoruje odlehlé hodnoty.

Dashboard podporuje porovnání verzí: vyberte dvě verze aplikace (aktuální a předchozí) pro vizuální porovnání metrik. Pokud se po aktualizaci 95. percentil doby spouštění zvýšil z 2,1 na 3,4 sekundy — regrese je zřejmá a je třeba najít commit, který zpomalení způsobil. Firebase Performance se integruje s GitHub, GitLab a Bitbucket, což umožňuje propojení změn metrik s konkrétními commity.

Příklady kódu pro Performance Monitoring

Podívejme se na příklady integrace Firebase Performance Monitoring v Android aplikaci v Kotlinu. Kód demonstruje vytvoření vlastního trasování pro měření načítání zpravodajského feedu, přidání HTTP atributu pro neautomaticky zachycený požadavek a použití Trace pro měření doby zpracování obrázku. Všechny příklady zohledňují možnost vypnutí sledování pomocí Remote Config.

Před použitím přidejte závislost: implementation("com.google.firebase:firebase-perf") přes Firebase BOM. Pro automatickou instrumentaci není nutná žádná další konfigurace — SDK automaticky zachycuje standardní operace po připojení závislosti.

Vlastní trasování pro načítání feedu

První příklad — měření doby načítání zpravodajského feedu ze serveru. Trasování obaluje asynchronní operaci fetchFeed, která získává data ze sítě a parsuje JSON. K trasování byly přidány vlastní atributy: zdroj dat (cache nebo network) a počet přijatých příspěvků. To umožňuje segmentovat data a pochopit, za jakých podmínek se feed načítá nejpomaleji.

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

Funkce loadFeedWithTrace přijímá parametr source („cache” nebo „network”), který se používá jako atribut trasování. Po dokončení asynchronní operace se trasování zastaví v bloku finally, což zaručuje zastavení i v případě výjimky. Metrika items_count umožňuje analyzovat, jak počet příspěvků ovlivňuje dobu načítání. V konzoli Firebase lze trasování filtrovat podle atributu source a zjistit, že načítání ze sítě je 3krát pomalejší než z cache.

HTTP atribut pro nestandardní požadavek

Druhý příklad — HTTP atribut pro požadavek provedený přes WebSocket (nezachycuje se automaticky). Používá se třída HttpMetric, která umožňuje ručně zaregistrovat URL požadavek, jeho metodu, kód odpovědi a velikost. Firebase zobrazí tento požadavek v sekci Network Requests spolu s automaticky zachycenými.

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

V příkladu sendWithHttpMetric používá newHttpMetric k registraci nestandardního HTTP volání. SDK jej nezachycuje automaticky, takže vývojář ručně nastavuje URL, metodu, kód odpovědi a velikosti. Je důležité nastavit URL bez parametrů dotazu (kvůli bezpečnosti a agregaci) — tedy /data, nikoli /data?token=abc. Firebase automaticky seskupuje podobné vzory URL.

Měření doby zpracování obrázku

Třetí příklad demonstruje měření doby zpracování obrázku (komprese, změna velikosti) pomocí vlastního trasování. V tomto případě trasování obaluje synchronní operaci, ale pro produkci použijte korutiny nebo RxJava, abyste neblokovali vlákno 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
}

Funkce compressImage měří dobu komprese obrázku do JPEG s kvalitou 80 %. Atribut format umožňuje budoucí porovnání doby komprese JPEG oproti WebP. Metrika output_size_kb ukazuje, jak účinná je komprese. V konzoli Firebase lze vidět rozdělení: na slabých zařízeních (levný Android) trvá komprese 4krát déle než na vlajkových lodích, což může být příčinou zpoždění při odesílání obrázků na server.

Jak zlepšit výkon na základě dat

Firebase Performance poskytuje data, ale nedává hotová řešení. Analýza metrik vyžaduje pochopení typických příčin degradace výkonu pro každou metriku. Podívejme se na hlavní vzorce zhoršení a způsoby jejich diagnostiky na základě dat Performance Monitoring. Přístup: najděte anomálii v metrice → zkontrolujte typické příčiny → aplikujte optimalizaci → zkontrolujte výsledek za týden.

Pomalý studený start (> 2 sekundy): příčiny — těžká inicializace SDK v Application.onCreate (analytika, crash reporting, map SDK), načítání velkých zdrojů (písma, motivy), synchronní operace v hlavním vlákně při startu. Řešení: líná inicializace SDK, odložené načítání zdrojů, použití SplashScreen API (Android 12+) pro zobrazení placeholder během inicializace. Firebase Performance ukáže, která verze aplikace začala startovat pomaleji — zkontrolujte, které závislosti byly přidány nebo aktualizovány.

Pomalé vykreslování obrazovky (> 500 ms): příčiny — složitá hierarchie View (vnořené ConstraintLayout, mnoho Fragment), načítání dat ve vlákně UI (síť nebo disk), těžké operace draw (velké obrázky, vlastní View). Řešení: optimalizace hierarchie rozvržení (Layout Inspector v Android Studio), přesun dat do vlákna na pozadí, ukládání obrázků do cache přes Glide nebo Coil. Použijte filtr Screen Rendering ve Firebase k nalezení nejpomalejší obrazovky a optimalizujte ji jako první.

Optimalizace síťových požadavků

Pomalé HTTP požadavky (> 3 sekundy): příčiny — pomalý server, velké payloady, chybějící cache, neoptimální protokol (HTTP/1.1 místo HTTP/2), DNS rozlišení. Řešení: zkontrolujte serverovou stranu (uptime, latency), zmenšete velikost odpovědi (stránkování, GraphQL, protobuf místo JSON), povolte ukládání do cache pomocí HTTP hlaviček (Cache-Control), použijte OkHttp Interceptor pro přidání časových limitů a logiky opakování.

Firebase Performance zobrazuje rozdělení času požadavku: DNS rozlišení, TCP handshake, TLS handshake, odeslání požadavku, přijetí odpovědi. Pokud většina času připadá na DNS — použijte přednačítání DNS (OkHttp DNS-over-HTTPS). Pokud na TLS — použijte obnovení relace a úpravu cipher suites. Pokud na přijetí odpovědi — zkontrolujte velikost odpovědi a rychlost sítě uživatele. Data Firebase umožňují lokalizovat problém na úrovni protokolu, nejen říct „požadavek je pomalý”.

Integrace Remote Config pro vypnutí sledování

Pro produkci se doporučuje přidat Remote Config příznak performance_tracing_enabled, který umožňuje vzdáleně vypnout vlastní trasování. Pokud Firebase Performance SDK na klientovi generuje příliš mnoho dat nebo ovlivňuje výkon (na slabých zařízeních), lze trasování vypnout pro všechny uživatele a ponechat pouze automatické metriky s minimální režií.

Příklad logiky: při startu aplikace zkontrolujeme parametr Remote Config performance_tracing_enabled. Pokud je false — všechna volání Firebase.performance.newTrace() vracejí stub objekt, který neshromažďuje data. To je implementováno pomocí wrapper třídy, která kontroluje příznak před vytvořením trasování. Tento přístup umožňuje podrobné sledování pro konkrétní uživatele (beta testery, vývojáře) bez ovlivnění celého publika.