Firebase Performance: wat is het, metrics en hoe te volgen

Wat is Firebase Performance Monitoring

Firebase Performance Monitoring is een SDK en cloudplatform voor het verzamelen, aggregeren en visualiseren van prestatiemetrics van mobiele apps. De SDK wordt in de app ingebed en instrumenteert automatisch de belangrijkste punten: de levenscyclus van Activity (Android) of ViewController (iOS), netwerkverzoeken via URLSession (iOS) of OkHttp (Android) en systeemaanroepen. De verzamelde gegevens worden naar de Firebase-server gestuurd, waar ze worden geaggregeerd op app-versie, apparaat, land en andere attributen.

De architectuur van de Performance SDK is gebaseerd op het principe van minimale overhead: instrumentatie voegt niet meer dan 1–2% toe aan de uitvoeringstijd van gemeten bewerkingen. Gegevens worden asynchroon verzameld en op het apparaat gebufferd voordat ze worden verzonden, waardoor de impact op de prestaties van de UI-thread wordt geëlimineerd. Het verzenden van gegevens gebeurt volgens schema (standaard elke 30 minuten) of wanneer de buffer van 100 KB is bereikt.

Het belangrijkste verschil tussen Firebase Performance en profilers zoals Android Studio (CPU Profiler) of Xcode Instruments is productiemonitoring. Firebase Performance verzamelt gegevens van echte gebruikersapparaten, niet alleen van ontwikkelaarsapparaten. Dit maakt het mogelijk problemen te detecteren die alleen op bepaalde modellen, OS-versies of in specifieke regio's voorkomen — problemen die niet in een gecontroleerde omgeving kunnen worden gereproduceerd.

Hoe de SDK gegevens verzamelt zonder code te wijzigen

Automatische instrumentatie is de belangrijkste functie van Firebase Performance. Voor Android registreert de SDK automatisch ActivityLifecycleCallbacks en meet de tijd tussen onCreate en onResume (schermrendertijd). Voor iOS — swizzlet het de methoden viewDidLoad en viewDidAppear. Netwerkverzoeken worden onderschept op het niveau van OkHttpInterceptor (Android) of NSURLProtocol (iOS). De ontwikkelaar hoeft geen start/stop-aanroepen toe te voegen voor standaard metrics.

In- en uitschakelen van de Performance SDK wordt beheerd via de Google Services-plugin (Android) of Info.plist (iOS). Voor debuggen kan verbose-logging van de Performance SDK worden ingeschakeld, die laat zien welke metrics worden verzameld en verzonden. In productie wordt aanbevolen logging op warning-niveau te houden om logs niet te vervuilen met onnodige informatie. Voor projecten op Flutter of React Native kan automatische instrumentatie beperkt zijn — meer details in de sectie codevoorbeelden.

Gratis limieten en tarifering

Firebase Performance wordt aangeboden op het gratis Spark-tarief zonder beperkingen op het aantal traces of gegevensvolume. Het betaalde Blaze-tarief brengt ook geen kosten in rekening voor Performance Monitoring — dit is een van de weinige Firebase-services die volledig gratis is op beide tarieven. Er is slechts één beperking: gegevens worden 30 dagen bewaard (op Spark) en tot 365 dagen (op Blaze). Voor langetermijnanalyse exporteert u gegevens via BigQuery export.

Geen kosten maakt Firebase Performance de ideale keuze voor elk project — van prototype tot enterprise-app met miljoenen gebruikers. De enige kostenpost is uitgaand verkeer van de Performance SDK-gegevens, maar dit is verwaarloosbaar in vergelijking met andere netwerkbewerkingen van de app (minder dan 1 MB per maand per apparaat). In BigQuery export worden kosten in rekening gebracht voor opslag en query's, maar de Performance SDK zelf is gratis.

Automatische metrics: wat wordt gemeten zonder code

Firebase Performance verzamelt automatisch vijf categorieën metrics zonder een enkele regel code: opstarttijd van de app (app start), trage verzoeken (slow HTTP requests), schermrendersnelheid (screen rendering), geheugengebruik (memory usage, alleen Android) en framesnelheid (frame rate, alleen Android). Deze metrics zijn direct beschikbaar in de Firebase-console na het aansluiten van de SDK en de eerste gebruikerssessie.

App Start Time — tijd vanaf het starten van het proces tot de volledige gereedheid van de UI voor interactie. Het wordt onderverdeeld in koude start (app start vanaf nul) en warme start (app wordt hersteld vanuit de achtergrond). Koude start omvat het laden van DEX-bestanden, initialisatie van statische velden, aanroep van Application.onCreate en Activity.onCreate. Firebase classificeert automatisch het starttype en toont de tijdsverdeling voor elk type.

Screen Rendering Time — tijd vanaf het begin van het laden van het scherm (onCreate voor Android, viewDidLoad voor iOS) tot het scherm gereed is voor interactie (onResume, viewDidAppear). Firebase aggregeert gegevens per scherm (op klassenaam of custom screen name), waardoor het mogelijk is te bepalen welk scherm het langst laadt. Voor Android wordt aanvullend dropped frames gemeten — het aantal frames dat is overgeslagen tijdens het renderen van het scherm (jank).

Netwerkverzoeken (HTTP/HTTPS)

Performance SDK onderschept en meet automatisch elk HTTP/HTTPS-verzoek dat vanuit de app wordt verzonden via URLSession, OkHttp of URLConnection. Voor elk verzoek worden geregistreerd: URL (pad zonder queryparameters voor veiligheid), HTTP-methode, antwoordcode, antwoordgrootte in bytes, duur van het verzoek en verbindingssnelheid (WiFi, Cellular). Gegevens worden geaggregeerd in het dashboard „Network Requests” van de Firebase-console.

Slow Requests — verzoeken waarvan de duur een ingestelde drempel overschrijdt. De standaarddrempel voor „traag verzoek” is 4000 ms. Deze metric is cruciaal voor het identificeren van problemen met de serverkant: als na een backend-update het aantal trage verzoeken is gestegen van 1% naar 15%, is dit een signaal voor onmiddellijke analyse van serverlogs. Gebruikers wachten niet langer dan 5 seconden op een antwoord — Firebase-gegevens tonen aan dat 53% van de gebruikers de app sluit als een verzoek langer dan 3 seconden duurt.

Beperkingen van automatische instrumentatie

iOS-beperkingen: op iOS kan de Performance SDK geen dropped frames meten (dit is een private API). Gebruik MetricKit of CADisplayLink om jank op iOS te meten. Ook onderschept de SDK op iOS geen verzoeken die via HTTP-clients van derden worden uitgevoerd die geen URLSession gebruiken (bijvoorbeeld SwiftNIO). Gebruik voor dergelijke gevallen aangepaste traces met HTTP-attributen.

Android-beperkingen: op Android is automatisch geheugenmeten alleen beschikbaar op apparaten met Android 8.0+ (API 26+). Gebruik voor oudere versies aangepaste traces met gegevens via Debug.getMemoryInfo(). De SDK onderschept ook geen WebSocket-verbindingen — hiervoor zijn aparte traces nodig. Ondanks de beperkingen dekken automatische metrics 80% van de behoeften aan prestatiemonitoring.

Aangepaste traces en HTTP-attributen

Aangepaste traces (custom traces) zijn benoemde tijdsintervallen die de ontwikkelaar handmatig maakt om de prestaties van specifieke scenario's te meten: laden van nieuwsfeed, verwerking van afbeeldingen, synchronisatie van gegevens, uitvoeren van complexe databasequery's. Aangepaste traces vullen automatische metrics aan en maken het mogelijk precies die codegedeelten te meten die de ontwikkelaar als kritiek voor de prestaties beschouwt.

Elke trace heeft een naam (maximaal 100 tekens) en kan tot 5 aangepaste metrics bevatten — numerieke waarden die binnen de trace worden geregistreerd. In de trace „image_processing” kunnen bijvoorbeeld de metrics „original_file_size” en „processed_file_size” worden gemeten. Metrics worden in de Firebase-console weergegeven als verdelingen (min, max, average, percentielen), waardoor niet alleen de duur maar ook de kenmerken van de bewerking kunnen worden geanalyseerd.

HTTP-attributen zijn een speciaal type aangepaste traces voor netwerkverzoeken die niet automatisch door de SDK zijn onderschept (bijvoorbeeld via WebSocket of bibliotheken van derden). HTTP-attributen omvatten URL, HTTP-methode, antwoordcode en antwoordgrootte. Firebase toont ze in het gedeelte „Network Requests” samen met automatisch verzamelde verzoeken, wat een uniform beeld geeft van netwerkinteracties.

Wanneer aangepaste traces gebruiken

Aangepaste traces zijn onmisbaar voor het meten van: laadtijd van gegevens uit lokale databases (Room, CoreData), duur van complexe berekeningen (encryptie, compressie), prestaties van animaties en overgangen, reactietijd van SDK's van derden (kaarten, betalingen, analyses). Maak voor elk dergelijk scenario een trace, omvat de gemeten code in start/stop en voeg attributen toe voor latere segmentatie.

Overdrijf niet met aangepaste traces. Elke trace betekent extra batterij- en dataverbruik. Het wordt aanbevolen niet meer dan 10–15 actieve traces te hebben in de productieversie van de app. Voor debuggen kunnen meer traces worden toegevoegd, maar schakel voor de release overtollige traces uit via Remote Config (gebruik de vlag performance_tracing_enabled). Dit maakt het mogelijk gedetailleerde tracering alleen in te schakelen voor geselecteerde gebruikers of sessies.

Trace-attributen voor segmentatie

Aangepaste attributen (custom attributes) zijn sleutel-waardeparen die aan een trace kunnen worden toegevoegd voor latere filtering in de Firebase-console. Aan de trace „feed_load” kunnen bijvoorbeeld de attributen „feed_type” (main, explore, following) en „cache_status” (cold, warm) worden toegevoegd. In de console kunnen trace-gegevens op deze attributen worden gefilterd om te bepalen welk feedtype het langzaamst laadt.

Beperkingen: elke trace kan maximaal 5 aangepaste attributen hebben. De waarde van een attribuut is een tekenreeks tot 100 tekens. Attributen moeten worden ingesteld voordat de trace start; wijziging van een attribuut na start wordt genegeerd. Deze beperking houdt verband met prestaties: het instellen van attributen na start zou extra synchronisatie vereisen.

Prestatiedrempels en waarschuwingen

Drempels (thresholds) zijn configureerbare grenswaarden van metrics waarbij Firebase Performance bij overschrijding een waarschuwing genereert. Drempels worden ingesteld in de Firebase-console (sectie Performance > Thresholds) voor elke automatische metric: app start time (cold/warm), screen rendering time, slow HTTP requests, HTTP response time. Er kunnen globale drempels voor alle app-versies of specifieke drempels voor bepaalde versies worden ingesteld.

Waarschuwingen (alerts) zijn automatische meldingen die Firebase verzendt bij overschrijding van een drempel. Waarschuwingen kunnen worden geconfigureerd voor e-mail, Slack webhook, PagerDuty of Cloud Functions (voor aangepaste verwerking). Elke waarschuwing bevat: metricnaam, huidige waarde, drempelwaarde, app-versie, segment (apparaat, land). Waarschuwingen maken het mogelijk te reageren op prestatievermindering voordat deze zichtbaar wordt voor gebruikers.

Aanbevolen drempels volgens industriestandaard (Google I/O 2025): koude start — minder dan 2 seconden, warme start — minder dan 1 seconde, schermrendering — minder dan 500 ms, HTTP-verzoekduur — minder dan 3000 ms (95e percentiel), aandeel trage verzoeken — minder dan 5%. Voor apps met hoge concurrentie (Social, E-commerce) kunnen de streefdrempels strenger zijn: koude start < 1.5 seconden, HTTP < 1000 ms.

Drempels instellen in de Firebase-console

In de Firebase-console gaat u naar de sectie Performance, opent u het tabblad Thresholds. Stel voor elke metric de gewenste drempelwaarde in en het percentage gebruikers waarop de overschrijding van toepassing moet zijn. Bijvoorbeeld: „beschouwen we een koude start als traag als deze voor meer dan 10% van de gebruikers langer dan 2 seconden duurt”. Firebase toont de huidige metricwaarden en overschrijdingsgeschiedenis om te helpen bij het kiezen van realistische drempels.

Belangrijk: drempels hebben geen invloed op het verzamelen van gegevens, ze beheren alleen het genereren van meldingen. Als de drempel te laag is (bijvoorbeeld koude start 1 seconde, terwijl 50% van de apparaten in 3 seconden start), zullen waarschuwingen constant binnenkomen en „ruis” worden die ontwikkelaars niet meer opmerken. Stel drempels in op basis van huidige indicatoren en verhoog ze geleidelijk naarmate u de app optimaliseert.

Performance Dashboard in de Firebase-console

Het Performance Dashboard toont de belangrijkste metrics als tijdreeksen met uitsplitsing naar app-versie, apparaat, land, verbindingstype en OS-versie. Voor elke metric zijn beschikbaar: gemiddelde, mediaan, 95e percentiel, 99e percentiel. Het 95e percentiel is de meest informatieve metric voor prestatie-evaluatie, omdat het laat zien hoe de app presteert op „slechte apparaten”, waarbij uitschieters worden genegeerd.

Het dashboard ondersteunt versievergelijking: selecteer twee app-versies (huidige en vorige) voor visuele vergelijking van metrics. Als na een update het 95e percentiel van de starttijd is gestegen van 2.1 naar 3.4 seconden — is de regressie duidelijk en moet de commit die de vertraging veroorzaakte worden gevonden. Firebase Performance integreert met GitHub, GitLab en Bitbucket, waardoor metricwijzigingen aan specifieke commits kunnen worden gekoppeld.

Codevoorbeelden voor Performance Monitoring

Laten we integratievoorbeelden van Firebase Performance Monitoring in een Android-app in Kotlin bekijken. De code demonstreert het maken van een aangepaste trace voor het meten van het laden van de nieuwsfeed, het toevoegen van een HTTP-attribuut voor een niet-automatisch onderschept verzoek en het gebruik van Trace voor het meten van de verwerkingstijd van een afbeelding. Alle voorbeelden houden rekening met de mogelijkheid om tracering uit te schakelen via Remote Config.

Voeg voor gebruik de afhankelijkheid toe: implementation("com.google.firebase:firebase-perf") via Firebase BOM. Voor automatische instrumentatie is geen extra configuratie nodig — de SDK onderschept standaardbewerkingen automatisch na het aansluiten van de afhankelijkheid.

Aangepaste trace voor het laden van de feed

Het eerste voorbeeld — het meten van de laadtijd van de nieuwsfeed van de server. De trace omvat de asynchrone bewerking fetchFeed, die gegevens uit het netwerk haalt en JSON parseert. Aan de trace zijn aangepaste attributen toegevoegd: gegevensbron (cache of network) en aantal ontvangen berichten. Dit maakt het mogelijk gegevens te segmenteren en te begrijpen onder welke omstandigheden de feed het langzaamst laadt.

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

De functie loadFeedWithTrace ontvangt de parameter source („cache” of „network”), die als trace-attribuut wordt gebruikt. Na voltooiing van de asynchrone bewerking wordt de trace gestopt in het finally-blok, wat stoppen garandeert, zelfs bij een uitzondering. De metric items_count maakt het mogelijk te analyseren hoe het aantal berichten de laadtijd beïnvloedt. In de Firebase-console kunnen traces op het attribuut source worden gefilterd en is te zien dat laden via het netwerk 3 keer langzamer is dan via de cache.

HTTP-attribuut voor een niet-standaard verzoek

Het tweede voorbeeld — HTTP-attribuut voor een verzoek dat via WebSocket wordt uitgevoerd (niet automatisch onderschept). De klasse HttpMetric wordt gebruikt om handmatig een URL-verzoek, de methode, antwoordcode en grootte te registreren. Firebase toont dit verzoek in het gedeelte Network Requests samen met automatisch onderschepte verzoeken.

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

In het voorbeeld gebruikt sendWithHttpMetric newHttpMetric om een niet-standaard HTTP-aanroep te registreren. De SDK onderschept deze niet automatisch, dus stelt de ontwikkelaar handmatig URL, methode, antwoordcode en groottes in. Het is belangrijk de URL in te stellen zonder queryparameters (voor veiligheid en aggregatie) — dus /data, niet /data?token=abc. Firebase groepeert automatisch vergelijkbare URL-patronen.

Meten van de verwerkingstijd van een afbeelding

Het derde voorbeeld demonstreert het meten van de tijd voor het verwerken van een afbeelding (compressie, formaatwijziging) met behulp van een aangepaste trace. In dit geval omvat de trace een synchrone bewerking, maar gebruik voor productie coroutines of RxJava om de UI-thread niet te blokkeren.

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
}

De functie compressImage meet de tijd voor het comprimeren van een afbeelding naar JPEG met 80% kwaliteit. Het attribuut format maakt toekomstige vergelijking mogelijk van compressietijd van JPEG versus WebP. De metric output_size_kb toont hoe efficiënt de compressie is. In de Firebase-console is de verdeling te zien: op zwakke apparaten (budget Android) duurt compressie 4 keer langer dan op vlaggenschepen, wat de oorzaak kan zijn van vertragingen bij het verzenden van afbeeldingen naar de server.

Hoe prestaties verbeteren op basis van gegevens

Firebase Performance levert gegevens, maar geeft geen kant-en-klare oplossingen. Analyse van metrics vereist inzicht in de typische oorzaken van prestatievermindering voor elke metric. Laten we de belangrijkste verslechteringspatronen en diagnostische methoden op basis van Performance Monitoring-gegevens bekijken. Aanpak: vind een anomalie in een metric → controleer typische oorzaken → pas optimalisatie toe → controleer het resultaat over een week.

Langzame koude start (> 2 seconden): oorzaken — zware SDK-initialisatie in Application.onCreate (analytics, crash reporting, map SDK), laden van grote bronnen (lettertypen, thema's), synchrone bewerkingen in de hoofdthread bij het opstarten. Oplossingen: luie SDK-initialisatie, uitgesteld laden van bronnen, gebruik van SplashScreen API (Android 12+) om een placeholder weer te geven tijdens initialisatie. Firebase Performance toont welke app-versie langzamer is gaan starten — controleer welke afhankelijkheden zijn toegevoegd of bijgewerkt.

Langzame schermrendering (> 500 ms): oorzaken — complexe View-hiërarchie (geneste ConstraintLayout, veel Fragmenten), laden van gegevens in de UI-thread (netwerk of schijf), zware draw-bewerkingen (grote afbeeldingen, aangepaste Views). Oplossingen: optimalisatie van de layouthiërarchie (Layout Inspector in Android Studio), verplaatsen van gegevens naar de achtergrondthread, cachen van afbeeldingen via Glide of Coil. Gebruik het Screen Rendering-filter in Firebase om het langzaamste scherm te vinden en als eerste te optimaliseren.

Optimalisatie van netwerkverzoeken

Trage HTTP-verzoeken (> 3 seconden): oorzaken — trage server, grote payloads, geen caching, niet-optimaal protocol (HTTP/1.1 in plaats van HTTP/2), DNS-resolutie. Oplossingen: controleer de serverkant (uptime, latency), verklein de antwoordgrootte (paginering, GraphQL, protobuf in plaats van JSON), schakel caching in via HTTP-headers (Cache-Control), gebruik OkHttp Interceptor voor het toevoegen van time-outs en herhaallogica.

Firebase Performance toont de tijdsverdeling van het verzoek: DNS-resolutie, TCP-handshake, TLS-handshake, verzoek verzenden, antwoord ontvangen. Als het grootste deel van de tijd aan DNS wordt besteed — gebruik dan vooraf laden van DNS (OkHttp DNS-over-HTTPS). Als aan TLS — gebruik dan session resumption en afstemming van cipher suites. Als aan het ontvangen van het antwoord — controleer dan de antwoordgrootte en de netwerksnelheid van de gebruiker. Firebase-gegevens maken het mogelijk het probleem op protocolniveau te lokaliseren, niet alleen te zeggen „het verzoek is traag”.

Remote Config-integratie voor het uitschakelen van tracering

Voor productie wordt aanbevolen een Remote Config-vlag performance_tracing_enabled toe te voegen, die het mogelijk maakt aangepaste traces op afstand uit te schakelen. Als de Firebase Performance SDK aan de clientkant te veel gegevens genereert of de prestaties beïnvloedt (op zwakke apparaten), kunnen traces voor alle gebruikers worden uitgeschakeld, waarbij alleen automatische metrics met minimale overhead overblijven.

Voorbeeld van logica: bij het starten van de app controleren we de Remote Config-parameter performance_tracing_enabled. Als deze false is — retourneren alle aanroepen van Firebase.performance.newTrace() een stub-object dat geen gegevens verzamelt. Dit wordt geïmplementeerd via een wrapper-klasse die de vlag controleert voordat een trace wordt gemaakt. Een dergelijke aanpak maakt het mogelijk gedetailleerde tracering in te schakelen voor specifieke gebruikers (bètatesters, ontwikkelaars) zonder het hele publiek te beïnvloeden.