Firebase Performance: vad är det, mått och hur man spårar

Vad är Firebase Performance Monitoring

Firebase Performance Monitoring är ett SDK och molnplattform för insamling, aggregering och visualisering av prestandamått för mobila appar. SDK:et bäddas in i appen och instrumenterar automatiskt nyckelpunkter: livscykeln för Activity (Android) eller ViewController (iOS), nätverksförfrågningar via URLSession (iOS) eller OkHttp (Android) och systemanrop. Insamlade data skickas till Firebase-servern där de aggregeras efter appversion, enhet, land och andra attribut.

Arkitekturen för Performance SDK är byggd på principen om minimal overhead: instrumentering tillför inte mer än 1–2 % till exekveringstiden för uppmätta operationer. Data samlas in asynkront och buffras på enheten innan de skickas, vilket eliminerar påverkan på prestandan för UI-tråden. Data skickas enligt schema (som standard var 30:e minut) eller när bufferten på 100 KB har uppnåtts.

Den viktigaste skillnaden mellan Firebase Performance och profilerare som Android Studio (CPU Profiler) eller Xcode Instruments är produktionsövervakning. Firebase Performance samlar in data från verkliga användarenheter, inte bara från utvecklarenheter. Detta gör det möjligt att upptäcka problem som bara uppstår på vissa modeller, OS-versioner eller i specifika regioner — det vill säga problem som inte kan reproduceras i en kontrollerad miljö.

Hur SDK samlar in data utan att ändra kod

Automatisk instrumentering är huvudfunktionen i Firebase Performance. För Android registrerar SDK automatiskt ActivityLifecycleCallbacks och mäter tiden mellan onCreate och onResume (skämrenderings tid). För iOS — swizzlar det metoderna viewDidLoad och viewDidAppear. Nätverksförfrågningar fångas upp på nivån OkHttpInterceptor (Android) eller NSURLProtocol (iOS). Utvecklaren behöver inte lägga till start/stop-anrop för standardmått.

Aktivering och avaktivering av Performance SDK hanteras via Google Services-plugin (Android) eller Info.plist (iOS). För felsökning kan utförlig loggning av Performance SDK aktiveras, vilket visar vilka mått som samlas in och skickas. I produktion rekommenderas att loggning hålls på warning-nivå för att inte fylla loggarna med onödig information. För projekt på Flutter eller React Native kan automatisk instrumentering vara begränsad — mer information i avsnittet kodexempel.

Gratis gränser och prissättning

Firebase Performance erbjuds på den kostnadsfria Spark-taxan utan begränsningar för antalet spårningar eller datavolym. Den betalda Blaze-taxan tar inte heller ut någon avgift för Performance Monitoring — detta är en av få Firebase-tjänster som är helt gratis på båda taxorna. Det finns bara en begränsning: data lagras i 30 dagar (på Spark) och upp till 365 dagar (på Blaze). För långsiktig analys exporterar du data via BigQuery export.

Ingen avgift gör Firebase Performance till ett idealiskt val för alla projekt — från prototyp till företagsapp med miljontals användare. Den enda kostnadsposten är utgående trafik för Performance SDK-data, men den är försumbar jämfört med andra nätverksoperationer i appen (mindre än 1 MB per månad per enhet). I BigQuery export tillkommer avgifter för lagring och frågor, men själva Performance SDK är gratis.

Automatiska mått: vad mäts utan kod

Firebase Performance samlar automatiskt in fem kategorier av mått utan en enda kodrad: appens starttid (app start), långsamma förfrågningar (slow HTTP requests), skärmrenderingshastighet (screen rendering), minnesanvändning (memory usage, endast Android) och bildhastighet (frame rate, endast Android). Dessa mått är tillgängliga i Firebase-konsolen direkt efter anslutning av SDK och första användarsessionen.

App Start Time — tid från processstart till full beredskap av UI för interaktion. Delas upp i kallstart (appen startar från noll) och varmstart (appen återställs från bakgrundsläge). Kallstart inkluderar inläsning av DEX-filer, initiering av statiska fält, anrop av Application.onCreate och Activity.onCreate. Firebase klassificerar automatiskt starttypen och visar tidsfördelningen för varje typ.

Screen Rendering Time — tid från början av skärminläsning (onCreate för Android, viewDidLoad för iOS) tills skärmen är redo för interaktion (onResume, viewDidAppear). Firebase aggregerar data för varje skärm (efter klassnamn eller anpassat skärmnamn), vilket gör det möjligt att avgöra vilken skärm som laddas långsammast. För Android mäts även hoppade bildrutor (dropped frames) — antalet bildrutor som hoppats över under skärmrendering (jank).

Nätverksförfrågningar (HTTP/HTTPS)

Performance SDK fångar automatiskt upp och mäter varje HTTP/HTTPS-förfrågan som skickas från appen via URLSession, OkHttp eller URLConnection. För varje förfrågan registreras: URL (sökväg utan frågeparametrar för säkerhet), HTTP-metod, svarskod, svarsstorlek i byte, förfrågans varaktighet och anslutningshastighet (WiFi, Cellular). Data aggregeras i instrumentpanelen „Network Requests” i Firebase-konsolen.

Slow Requests — förfrågningar vars varaktighet överstiger ett inställt tröskelvärde. Standardtröskeln för „långsam förfrågan” är 4000 ms. Detta mått är kritiskt för att identifiera problem med serversidan: om antalet långsamma förfrågningar ökat från 1 % till 15 % efter en backend-uppdatering är detta en signal för omedelbar analys av serverloggar. Användare kommer inte att vänta på ett svar längre än 5 sekunder — Firebase-data visar att 53 % av användarna stänger appen om en förfrågan tar längre tid än 3 sekunder.

Begränsningar för automatisk instrumentering

iOS-begränsningar: på iOS kan Performance SDK inte mäta hoppade bildrutor (detta är ett privat API). För att mäta jank på iOS, använd MetricKit eller CADisplayLink. SDK fångar inte heller upp förfrågningar som görs via tredjeparts HTTP-klienter som inte använder URLSession (t.ex. SwiftNIO). För sådana fall, använd anpassade spårningar med HTTP-attribut.

Android-begränsningar: på Android är automatisk minnesmätning endast tillgänglig på enheter med Android 8.0+ (API 26+). För äldre versioner, använd anpassade spårningar med datainsamling via Debug.getMemoryInfo(). SDK fångar inte heller upp WebSocket-anslutningar — för dessa behövs separata spårningar. Trots begränsningarna täcker automatiska mått 80 % av behoven för prestandaövervakning.

Anpassade spårningar och HTTP-attribut

Anpassade spårningar (custom traces) är namngivna tidsintervall som utvecklaren skapar manuellt för att mäta prestanda för specifika scenarier: ladda nyhetsfeed, bearbeta bild, synkronisera data, utföra komplex databasfråga. Anpassade spårningar kompletterar automatiska mått och gör det möjligt att mäta exakt de koddelar som utvecklaren anser vara kritiska för prestanda.

Varje spårning har ett namn (max 100 tecken) och kan innehålla upp till 5 anpassade mått (metrics) — numeriska värden som registreras inom spårningen. Till exempel i spårningen „image_processing” kan måtten „original_file_size” och „processed_file_size” mätas. Mått visas i Firebase-konsolen som fördelningar (min, max, average, percentiler), vilket gör det möjligt att analysera inte bara varaktighet utan också operationens egenskaper.

HTTP-attribut är en speciell typ av anpassade spårningar för nätverksförfrågningar som inte automatiskt fångats upp av SDK (t.ex. via WebSocket eller tredjepartsbibliotek). HTTP-attribut inkluderar URL, HTTP-metod, svarskod och svarsstorlek. Firebase visar dem i avsnittet „Network Requests” tillsammans med automatiskt insamlade förfrågningar, vilket ger en enhetlig bild av nätverksinteraktioner.

När ska anpassade spårningar användas

Anpassade spårningar är oumbärliga för att mäta: tid för datainläsning från lokal databas (Room, CoreData), varaktighet för komplexa beräkningar (kryptering, komprimering), prestanda för animationer och övergångar, svarstid för tredjeparts-SDK (kartor, betalningar, analys). För varje sådant scenario, skapa en spårning, omge den uppmätta koden med start/stop och lägg till attribut för senare segmentering.

Missbruka inte anpassade spårningar. Varje spårning innebär extra batteri- och dataförbrukning. Det rekommenderas högst 10–15 aktiva spårningar i produktionsversionen av appen. För felsökning kan fler spårningar läggas till, men innan lansering, inaktivera överflödiga via Remote Config (använd flaggan performance_tracing_enabled). Detta gör det möjligt att aktivera detaljerad spårning endast för utvalda användare eller sessioner.

Spårningsattribut för segmentering

Anpassade attribut (custom attributes) är nyckel-värdepar som kan läggas till en spårning för senare filtrering i Firebase-konsolen. Till exempel kan attributen „feed_type” (main, explore, following) och „cache_status” (cold, warm) läggas till spårningen „feed_load”. I konsolen kan spårningsdata filtreras efter dessa attribut för att avgöra vilken feedtyp som laddas långsammast.

Begränsningar: varje spårning kan ha upp till 5 anpassade attribut. Attributvärdet är en sträng på upp till 100 tecken. Attribut måste ställas in innan spårningen startar; ändring av attribut efter start ignoreras. Denna begränsning är relaterad till prestanda: inställning av attribut efter start skulle kräva ytterligare synkronisering.

Prestandatrösklar och varningar

Trösklar (thresholds) är konfigurerbara gränsvärden för mått, vid överskridande av vilka Firebase Performance genererar en varning. Trösklar ställs in i Firebase-konsolen (avsnittet Performance > Thresholds) för varje automatiskt mått: app start time (cold/warm), screen rendering time, slow HTTP requests, HTTP response time. Globala trösklar kan ställas in för alla appversioner eller specifika för vissa versioner.

Varningar (alerts) är automatiska meddelanden som Firebase skickar vid överskridande av en tröskel. Varningar kan konfigureras för e-post, Slack webhook, PagerDuty eller Cloud Functions (för anpassad bearbetning). Varje varning innehåller: måttnamn, aktuellt värde, tröskelvärde, appversion, segment (enhet, land). Varningar gör det möjligt att reagera på prestandaförsämring innan den blir synlig för användarna.

Rekommenderade trösklar enligt branschstandard (Google I/O 2025): kallstart — mindre än 2 sekunder, varmstart — mindre än 1 sekund, skärmrendering — mindre än 500 ms, HTTP-förfrågans varaktighet — mindre än 3000 ms (95:e percentilen), andel långsamma förfrågningar — mindre än 5 %. För appar med hög konkurrens (Social, E-commerce) kan måltrösklarna vara strängare: kallstart < 1,5 sekunder, HTTP < 1000 ms.

Inställning av trösklar i Firebase-konsolen

I Firebase-konsolen gå till avsnittet Performance, öppna fliken Thresholds. För varje mått, ställ in önskat tröskelvärde och den andel användare som ska påverkas av överskridandet. Till exempel: „anser vi att kallstart är långsam om den överstiger 2 sekunder för mer än 10 % av användarna”. Firebase kommer att visa aktuella måttvärden och historik över överskridanden för att hjälpa till att välja realistiska trösklar.

Viktigt: trösklar påverkar inte datainsamlingen, de styr bara genereringen av meddelanden. Om tröskeln är för låg (till exempel kallstart 1 sekund, även om 50 % av enheterna startar på 3 sekunder) kommer varningarna att komma ständigt och bli „brus” som utvecklare slutar lägga märke till. Ställ in trösklar baserat på aktuella indikatorer och skärp dem sedan gradvis när du optimerar appen.

Performance Dashboard i Firebase-konsolen

Performance Dashboard visar nyckelmått som tidsserier med uppdelning efter appversion, enhet, land, anslutningstyp och OS-version. För varje mått finns tillgängligt: medelvärde, median, 95:e percentil, 99:e percentil. Den 95:e percentilen är det mest informativa måttet för prestandautvärdering eftersom det visar hur appen presterar på „svaga enheter” och ignorerar avvikande värden.

Dashboarden stödjer versionsjämförelse: välj två appversioner (aktuell och tidigare) för visuell jämförelse av mått. Om den 95:e percentilen för starttid efter en uppdatering ökat från 2,1 till 3,4 sekunder — är regressionen uppenbar och commiten som orsakade inbromsningen måste hittas. Firebase Performance integreras med GitHub, GitLab och Bitbucket, vilket gör det möjligt att koppla måttförändringar till specifika commits.

Kodexempel för Performance Monitoring

Låt oss titta på exempel på integration av Firebase Performance Monitoring i en Android-app i Kotlin. Koden visar hur man skapar en anpassad spårning för att mäta inläsning av nyhetsfeed, lägger till ett HTTP-attribut för en icke-automatiskt fångad förfrågan och använder Trace för att mäta bildbehandlingstiden. Alla exempel tar hänsyn till möjligheten att inaktivera spårning via Remote Config.

Innan användning, lägg till beroendet: implementation("com.google.firebase:firebase-perf") via Firebase BOM. För automatisk instrumentering krävs ingen ytterligare konfiguration — SDK fångar automatiskt upp standardoperationer efter att beroendet anslutits.

Anpassad spårning för feedinläsning

Första exemplet — mätning av inläsningstid för nyhetsfeed från servern. Spårningen omsluter den asynkrona operationen fetchFeed, som hämtar data från nätverket och tolkar JSON. Till spårningen har anpassade attribut lagts till: datakälla (cache eller network) och antal mottagna inlägg. Detta gör det möjligt att segmentera data och förstå under vilka förhållanden feeden laddas långsammast.

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

Funktionen loadFeedWithTrace tar emot parametern source („cache” eller „network”), som används som spårningsattribut. Efter att den asynkrona operationen slutförts stoppas spårningen i finally-blocket, vilket garanterar stopp även vid undantag. Måttet items_count gör det möjligt att analysera hur antalet inlägg påverkar inläsningstiden. I Firebase-konsolen kan spårningar filtreras efter attributet source och man kan se att inläsning från nätverket är 3 gånger långsammare än från cache.

HTTP-attribut för icke-standard förfrågan

Andra exemplet — HTTP-attribut för en förfrågan som utförs via WebSocket (fångas inte automatiskt). Klassen HttpMetric används, som möjliggör manuell registrering av en URL-förfrågan, dess metod, svarskod och storlek. Firebase kommer att visa denna förfrågan i avsnittet Network Requests tillsammans med automatiskt fångade.

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

I exemplet använder sendWithHttpMetric newHttpMetric för att registrera ett icke-standard HTTP-anrop. SDK fångar det inte automatiskt, så utvecklaren ställer manuellt in URL, metod, svarskod och storlekar. Det är viktigt att ställa in URL utan frågeparametrar (för säkerhet och aggregering) — det vill säga /data, inte /data?token=abc. Firebase grupperar automatiskt liknande URL-mönster.

Mätning av bildbehandlingstid

Tredje exemplet visar mätning av tid för bildbehandling (komprimering, storleksändring) med hjälp av en anpassad spårning. I detta fall omsluter spårningen en synkron operation, men för produktion, använd coroutines eller RxJava för att inte blockera UI-tråden.

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
}

Funktionen compressImage mäter tiden för komprimering av bild till JPEG med 80 % kvalitet. Attributet format möjliggör framtida jämförelse av komprimeringstid för JPEG vs WebP. Måttet output_size_kb visar hur effektiv komprimeringen är. I Firebase-konsolen kan fördelningen ses: på svaga enheter (budget Android) tar komprimeringen 4 gånger längre tid än på flaggskepp, vilket kan vara orsaken till fördröjningar vid sändning av bilder till servern.

Hur man förbättrar prestanda baserat på data

Firebase Performance tillhandahåller data, men ger inga färdiga lösningar. Analys av mått kräver förståelse för de typiska orsakerna till prestandaförsämring för varje mått. Låt oss titta på de viktigaste försämringsmönstren och metoderna för att diagnostisera dem baserat på Performance Monitoring-data. Tillvägagångssätt: hitta en avvikelse i måttet → kontrollera typiska orsaker → tillämpa optimering → kontrollera resultatet om en vecka.

Långsam kallstart (> 2 sekunder): orsaker — tung SDK-initiering i Application.onCreate (analys, krashrapportering, kart-SDK), inläsning av stora resurser (teckensnitt, teman), synkrona operationer i huvudtråden vid start. Lösningar: lat SDK-initiering, fördröjd resursinläsning, användning av SplashScreen API (Android 12+) för att visa en placeholder under initiering. Firebase Performance kommer att visa vilken appversion som börjat starta långsammare — kontrollera vilka beroenden som lagts till eller uppdaterats.

Långsam skärmrendering (> 500 ms): orsaker — komplex View-hierarki (nästlade ConstraintLayout, många Fragment), inläsning av data i UI-tråden (nätverk eller disk), tunga draw-operationer (stora bilder, anpassade View). Lösningar: optimering av layout-hierarki (Layout Inspector i Android Studio), flytta data till bakgrundstråd, cachning av bilder via Glide eller Coil. Använd Screen Rendering-filtret i Firebase för att hitta den långsammaste skärmen och optimera den först.

Optimering av nätverksförfrågningar

Långsamma HTTP-förfrågningar (> 3 sekunder): orsaker — långsam server, stora payloads, ingen cachning, icke-optimalt protokoll (HTTP/1.1 istället för HTTP/2), DNS-upplösning. Lösningar: kontrollera serversidan (uptime, latency), minska svarsstorleken (paginering, GraphQL, protobuf istället för JSON), aktivera cachning via HTTP-huvuden (Cache-Control), använd OkHttp Interceptor för att lägga till timeout och återförsökslogik.

Firebase Performance visar tidsfördelningen för förfrågan: DNS-upplösning, TCP-handskakning, TLS-handskakning, sändning av förfrågan, mottagning av svar. Om största delen av tiden läggs på DNS — använd förhandsinläsning av DNS (OkHttp DNS-over-HTTPS). Om på TLS — använd återanvändning av session och justering av cipher suites. Om på mottagning av svar — kontrollera svarsstorleken och användarens nätverkshastighet. Firebase-data gör det möjligt att lokalisera problemet på protokollnivå, inte bara säga „förfrågan är långsam”.

Remote Config-integration för att inaktivera spårning

För produktion rekommenderas att lägga till en Remote Config-flagga performance_tracing_enabled, som möjliggör fjärrinaktivering av anpassade spårningar. Om Firebase Performance SDK på klientsidan genererar för mycket data eller påverkar prestandan (på svaga enheter) kan spårningar inaktiveras för alla användare och endast automatiska mått med minimal overhead behållas.

Logikexempel: när appen startar kontrollerar vi Remote Config-parametern performance_tracing_enabled. Om den är false — returnerar alla anrop till Firebase.performance.newTrace() ett stub-objekt som inte samlar in data. Detta implementeras via en wrapper-klass som kontrollerar flaggan innan spårningen skapas. Ett sådant tillvägagångssätt gör det möjligt att aktivera detaljerad spårning för specifika användare (bettatestare, utvecklare) utan att påverka hela publiken.