Firebase Performance Monitoring är ett kostnadsfritt verktyg från Google för att övervaka prestanda hos mobilapplikationer i realtid. Tjänsten samlar automatiskt in mätvärden för starttid, skärmrenderingshastighet och varaktighet för HTTP-förfrågningar, utan att kräva kodskrivning för grundläggande scenarier. Enligt data från Google Firebase, 2025, spårar SDK automatiskt upp till 90% av nätverksförfrågningarna utan ytterligare konfiguration. Verktyget finns tillgängligt för Android, iOS och webbapplikationer inom Firebase-ekosystemet.
Huvudpunkter
Firebase Performance Monitoring är en molntjänst från Google som samlar in och visar prestandamätvärden för mobilapplikationer. Tjänsten ingår i Firebase-verktygssatsen och kräver ingen separat betalning — övervakning finns tillgänglig inom ramen för den kostnadsfria Spark-prenumerationen (gräns på 500 000 händelser per dag) och den betalda Blaze-prenumerationen. Firebase Performance genererar automatiskt spårningar för standardscenarier: cold start av skärm, warm start, bakgrunds-HTTP-förfrågningar.
Tjänstens arkitektur bygger på två datatyper: traces (spårningar) och metrics (mätvärden). En spårning är ett tidsintervall med början och slut, inom vilket exekveringstiden mäts. Ett mätvärde är ett numeriskt värde: svarsstorlek, felfrekvens, hastighet i byte/sek. Varje spårning kan innehålla flera mätvärden. SDK samlar in data på enheten, buffrar dem och skickar dem i bakgrunden till Firebase med låg latensprioritet för att inte påverka användarupplevelsen.
Enligt rapporten från Google I/O 2024 används Firebase Performance i över 2 miljoner applikationer världen över. Den genomsnittliga tiden att upptäcka ett prestandaproblem med Firebase Performance är 15 minuter efter lansering, om aviseringar är konfigurerade. Utan övervakning upptäcks ett liknande problem i genomsnitt efter 2-3 dagar baserat på användarklagomål till supporten.
Crashlytics spårar krascher och allvarliga fel — situationer där applikationen oväntat stannar. Firebase Performance övervakar prestandan hos den körbara applikationen: långsamma skärmar, långa nätverksförfrågningar, fördröjningar i UI-svar. Crashlytics svarar på frågan ”varför kraschade applikationen?“, medan Performance svarar på frågan ”varför fungerar applikationen långsamt?“. Båda tjänsterna integreras via ett SDK (Firebase Core) och data visas i relaterade sektioner av Firebase-konsolen.
Firebase Performance visar inte genomsnittliga värden — endast percentiler: P50, P75, P90, P95, P99. Detta är kritiskt för prestanda: genomsnittstiden döljer avvikande värden. Om 99 användare öppnar skärmen på 200 ms och en på 20 sekunder, blir genomsnittet ~400 ms, vilket ser acceptabelt ut. P99 visar 20 sekunder — det verkliga problemet. Firebase visar percentiler på en tidsaxel, vilket gör det möjligt att spåra regressioner med en noggrannhet på upp till en timme.
Firebase Performance SDK integreras i applikationen via standardintegration: lägga till ett beroende i Gradle (Android) eller via CocoaPods (iOS). Efter initialisering av Firebase i koden börjar SDK automatiskt samla in mätvärden utan ytterligare konfiguration. En viktig arbetsprincip är lazy collection: SDK skickar inte data omedelbart, utan ackumulerar dem och skickar dem i batchar när nätverksförhållandena är gynnsamma.
För iOS använder SDK NSURLProtocol för att fånga upp HTTP-förfrågningar, för Android — OkHttp Interceptor. Om applikationen inte använder OkHttp, omsluter SDK automatiskt HttpURLConnection. Uppfångade förfrågningar berikas med metadata: Content-Type, svarsstatus, storlek i byte, varaktighet. All data överförs via HTTPS till Firebase-servern med TLS 1.3-kryptering.
Ett av de viktigaste kraven för Firebase Performance är att vara den sista pluginen i listan över Gradle-plugins. Om ordningen bryts kan SDK misslyckas med att fånga upp alla förfrågningar eller mäta starttiden felaktigt. Firebase rekommenderar att pluginen placeras i slutet av plugins-blocket, efter Crashlytics och andra Google Services-plugins.
// build.gradle (Module: app) — korrekt ordning på plugins
plugins {
id "com.android.application"
id "org.jetbrains.kotlin.android"
id "com.google.gms.google-services"
id "com.google.firebase.crashlytics"
id "com.google.firebase.firebase-perf" // sist!
}
dependencies {
implementation platform("com.google.firebase:firebase-bom:33.0.0")
implementation "com.google.firebase:firebase-perf"
}
Firebase Performance skapar tre typer av automatiska spårningar: screen trace (skärmrenderings tid), app start trace (applikationens starttid) och network request trace (HTTP-förfrågningar). Screen trace för Android mäter tiden mellan anropet till Activity.onCreate och slutförandet av renderingen av den första bildrutan. För iOS mäts tiden mellan viewDidLoad och viewDidAppear. Firebase skapar automatiskt en spårning för varje skärm med hjälp av klassnamnet för Activity eller ViewController.
App start trace är uppdelad i två typer: cold start (applikationen startar från början, processen fanns inte) och warm start (applikationen återställs från bakgrundsstatus). Cold start är den mest kritiska indikatorn eftersom den inkluderar initialisering av alla SDK:er, laddning av DEX-filer och skapande av den första Activity. Firebase mäter cold start från det att processen startar till dess att den första skärmen är helt renderad. Enligt Googles rekommendationer bör cold start inte överstiga 500 ms för P50 och 2 sekunder för P99.
Network request trace registrerar automatiskt varje HTTP-förfrågan med metadata: URL, metod, svarskod, svarsstorlek, överföringshastighet. I Firebase Performance-konsolen kan förfrågningar filtreras efter URL-mönster — till exempel visa alla förfrågningar till /api/v2/orders. För varje mönster visas percentiler för svarstid och frekvensen av 4xx/5xx-fel. Detta gör det möjligt att snabbt upptäcka försämring av en specifik API utan att konfigurera separata aviseringar.
För skärmar beräknar Firebase Performance också mätvärdet ”frozen frames“ — bildrutor som renderades längre än 700 ms. Sådana UI-frysningar upplevs av användaren som ”applikationen har frusit“. Om en skärm har mer än 1% frozen frames markerar Firebase mätvärdet som problematiskt. För Android samlar SDK också in mätvärdet slow renders — bildrutor längre än 16 ms (förlust av 60 FPS). Kombinationen av screen trace och frozen frames ger en komplett bild av både laddningstid och animationsjämnhet.
Anpassade spårningar gör det möjligt att mäta varaktigheten för alla användarscenarier: beställning, uppladdning av bild till molnet, datasynkronisering. Utvecklaren anger explicit början och slut på spårningen i koden och namnger scenariot. Till skillnad från automatiska spårningar ger anpassade spårningar full kontroll över vad som mäts och gör det möjligt att lägga till attribut för filtrering.
Varje anpassad spårning kan innehålla attribut — nyckel-värdepar som läggs till som metadata. Attribut hjälper till att segmentera data: till exempel kan beställningstiden spåras separat för ”promo_user” och ”regular_user”. Firebase Performance stöder upp till 5 attribut per spårning och upp till 100 unika attributvärden. Attribut indexeras och är tillgängliga för filtrering i Firebase-konsolen.
Enligt rapporten från Google I/O 2024 använder Spotify-teamet anpassade Firebase-spårningar för att övervaka tiden för växling mellan låtar. Detta gjorde det möjligt att minska medianväxlingstiden från 400 ms till 120 ms genom att identifiera en flaskhals i ljudbuffertcachen. Den viktigaste insikten var filtrering efter attributet ”device_model” — problemet uppträdde endast på Samsung-enheter med Android 13.
import com.google.firebase.perf.FirebasePerformance
import com.google.firebase.perf.metrics.Trace
class CheckoutTracker {
private val firebasePerf = FirebasePerformance.getInstance()
fun trackCheckoutFlow(userId: String, promoApplied: Boolean) {
val trace: Trace = firebasePerf.newTrace("checkout_flow")
trace.putAttribute("promo_user", promoApplied.toString())
trace.putAttribute("user_tier", "premium")
trace.start()
// Genomförande av beställningsscenario
validateCart()
processPayment()
confirmOrder()
trace.stop()
}
}
Integrering av Firebase Performance i Android kräver tre steg: lägga till google-services-plugin, ansluta Firebase BOM (Bill of Materials) och lägga till firebase-perf-beroendet. Firebase Performance fungerar automatiskt på alla Activity och fragment om de använder AppCompatActivity. För Compose-skärmar rekommenderar Firebase användning av anpassade spårningar eftersom automatisk screen trace inte stöder Compose direkt.
En viktig detalj: Firebase Performance Gradle-plugin modifierar applikationens bytekod under kompileringsfasen. Pluginen lägger till instrumenteringskod i varje Activity och OkHttp-klient. Detta kan öka byggtiden med 5-10% och APK-storleken med 200-400 KB. I debug-builds inaktiveras Firebase Performance automatiskt — detta skyddar mot förvrängning av mätvärden under lokal utveckling. För tvångsaktivering i debug används flaggan firebasePerformanceInstrumentationEnabled i manifestet.
Firebase Performance stöder också MetricKit för iOS och Perfetto för Android — lågnivåsystemspårare. MetricKit tillhandahåller data om bildrutefrekvens, CPU- och minnesförbrukning på operativsystemsnivå. Firebase aggregerar dessa data och visar dem i samma konsol där HTTP-spårningar och screen traces visas, och kombinerar system- och applikationstelemetri i ett gränssnitt.
import okhttp3.OkHttpClient
import com.google.firebase.perf.network.FirebasePerfOkHttpClient
val client = OkHttpClient.Builder()
.addInterceptor FirebasePerfOkHttpClient
.build()
val request = Request.Builder()
.url("https://api.example.com/orders")
.build()
client.newCall(request).enqueue(object : Callback {
override fun onFailure(call: Call, e: IOException) { /* handle */ }
override fun onResponse(call: Call, response: Response) { /* handle */ }
})
För iOS sker integrering av Firebase Performance via CocoaPods eller Swift Package Manager. Efter installation av poddar FirebasePerformance och FirebaseCore börjar SDK automatiskt samla in mätvärden. För att fånga upp HTTP-förfrågningar använder Firebase Performance iOS NSURLProtocol — en systemmekanism som gör det möjligt att fånga upp alla URL-laddningar i applikationen. SDK registrerar sin egen NSURLProtocol-underklass vid start, och alla förfrågningar via URLSession hamnar automatiskt under övervakning.
Begränsning för iOS: Firebase Performance stöder inte automatisk screen trace för SwiftUI. För SwiftUI-applikationer måste anpassade spårningar skapas manuellt genom att omsluta View-kroppen i ett start/stopp-block. Firebase arbetar med inbyggt stöd för SwiftUI, men för närvarande spårar SDK automatiskt endast UIView-kontroller. För hybridapplikationer på UIKit + SwiftUI rekommenderas att skärmar skapas i UIKit och SwiftUI bäddas in via UIHostingController.
Firebase Performance iOS erbjuder också integration med MetricKit — Apple-ramverket som samlar in diagnostisk data på operativsystemsnivå. MetricKit skickar dagliga rapporter med CPU-, GPU-, minnes- och bildrutefrekvensmätvärden. Firebase Performance aggregerar dessa rapporter och visar dem i konsolen bredvid anpassade spårningar, vilket ger en komplett bild av prestanda både på applikations- och systemnivå.
import FirebasePerformance
final class ImageUploadService {
func uploadImage(_ data: Data, to url: URL) async throws {
guard let trace = Performance.startTrace(name: "image_upload") else { return }
trace?.setValue("image/jpeg", forAttribute: "content_type")
trace?.setValue("\(data.count)", forAttribute: "file_size")
var request = URLRequest(url: url)
request.httpMethod = "POST"
request.httpBody = data
let (_, response) = try await URLSession.shared.data(for: request)
guard let httpResponse = response as? HTTPURLResponse else { return }
trace?.setValue("\(httpResponse.statusCode)",
forAttribute: "status_code")
trace?.stop()
}
}
Vanliga frågor
Ja, Firebase Performance är tillgängligt på kostnadsfritt Spark-abonnemang med en gräns på 500 000 händelser per dag. För projekt med större datavolym används Blaze-abonnemanget med betalning per användning: 0,0003 dollar per 1000 händelser över gränsen. För de flesta startups och medelstora projekt är 500 000 händelser per dag mer än tillräckligt.
Firebase Performance SDK är optimerat för minimal påverkan. Dataöverföring sker i en bakgrundstråd med låg prioritet. Enligt Googles tester är SDK:ns påverkan på starttiden mindre än 1%. SDK-storleken är cirka 300 KB för Android och 250 KB för iOS.
Automatiskt samlas app start (cold/warm), screen rendering (renderingstid för varje skärm), HTTP-förfrågningar (tid, storlek, status) och frozen frames in. För Android samlas även frekvensen av slow renders (>16 ms) och ANR in.
Firebase Performance inaktiveras automatiskt i felsökningsläge. För tvångskontroll används en flagga i Android-manifestet: firebasePerformanceInstrumentationEnabled. För iOS görs inaktivering via flaggan -FIRPerformanceEnabled NO i argumenten för startschemat.
Ja, Firebase Performance stöder export till BigQuery. När projektet är anslutet till BigQuery dupliceras alla mätvärden automatiskt till BigQuery-tabeller, tillgängliga för SQL-frågor och skapande av instrumentpaneler i Looker Studio. Exporten konfigureras i avsnittet Integrations i Firebase-konsolen.
Sammanfattning
Vi utvecklar en mobil applikation nyckelfärdigt
IT Sectr skapar iOS- och Android-applikationer för startups och företag sedan 2017. Vi ger dig råd och föreslår den bästa lösningen.
Läs också