Firebase Performance: bu nədir, metrikalar və necə izləmək olar

Firebase Performance Monitoring nədir

Firebase Performance Monitoring — mobil tətbiqlərin performans metrikalarını toplamaq, aqreqasiya etmək və vizuallaşdırmaq üçün SDK və bulud platformasıdır. SDK tətbiqə daxil edilir və avtomatik olaraq əsas nöqtələri instrumentasiya edir: Activity (Android) və ya ViewController (iOS) həyat dövrü, URLSession (iOS) və ya OkHttp (Android) vasitəsilə şəbəkə sorğuları və sistem çağırışları. Toplanmış məlumatlar Firebase serverinə göndərilir və tətbiq versiyaları, cihazlar, ölkələr və digər atributlar üzrə aqreqasiya edilir.

Performance SDK-nın arxitekturası minimal yük prinsipi üzrə qurulmuşdur: instrumentasiya ölçülən əməliyyatların vaxtına 1–2%-dən çox əlavə etmir. Məlumatlar asinxron şəkildə toplanır və göndərilməzdən əvvəl cihazda buferləşdirilir ki, bu da UI axınının performansına təsiri aradan qaldırır. Məlumatların göndərilməsi cədvəl üzrə (standart olaraq hər 30 dəqiqədə bir) və ya 100 KB bufer həcminə çatdıqda baş verir.

Firebase Performance-ın Android Studio (CPU Profiler) və ya Xcode Instruments profilerlərindən əsas fərqi istehsal monitorinqidir. Firebase Performance məlumatları yalnız tərtibatçı cihazlarından deyil, real istifadəçi cihazlarından toplayır. Bu, yalnız müəyyən modellərdə, ƏŹ versiyalarında və ya xüsusi regionlarda təkrarlanan problemləri aşkarlamağa imkan verir — yəni idarə olunan mühitdə təkrarlana bilməyən problemləri.

SDK kod dəyişdirmədən məlumatları necə toplayır

Avtomatik instrumentasiya — Firebase Performance-ın əsas xüsusiyyətidir. Android üçün SDK avtomatik olaraq ActivityLifecycleCallbacks qeydiyyatdan keçirir və onCreate ilə onResume arasındakı vaxtı (ekran render vaxtı) ölçür. iOS üçün — viewDidLoad və viewDidAppear metodlarını swizzle edir. Şəbəkə sorğuları OkHttpInterceptor (Android) və ya NSURLProtocol (iOS) səviyyəsində ələ keçirilir. Tərtibatçı standart metrikalar üçün start/stop çağırışları əlavə etməlidir.

Performance SDK-nın aktivləşdirilməsi və söndürülməsi Google Services plagin (Android) və ya Info.plist (iOS) vasitəsilə idarə olunur. Debug üçün Performance SDK-nın verbose loqlarını aktivləşdirmək olar ki, bu da hansı metrikaların toplandığını və göndərildiyini göstərir. İstehsalda loqları warning səviyyəsində saxlamaq tövsiyə olunur ki, əlavə məlumatla loqları zibilləməyəsiniz. Flutter və ya React Native layihələri üçün avtomatik instrumentasiya məhdud ola bilər — ətraflı məlumat kod nümunələri bölməsindədir.

Pulsuz limitlər və tariflər

Firebase Performance Spark pulsuz tarifində izlərin sayı və ya məlumat həcmi ilə bağlı məhdudiyyətlər olmadan təklif olunur. Blaze pullu tarifi də Performance Monitoring üçün ödəniş tələb etmir — bu, hər iki tarifdə tamamilə pulsuz olan az sayda Firebase xidmətlərindən biridir. Yalnız bir məhdudiyyət var: məlumatlar 30 gün (Spark) və 365 günə qədər (Blaze) saxlanılır. Uzunmüddətli təhlil üçün məlumatları BigQuery export vasitəsilə ixrac edin.

Ödənişsiz olması Firebase Performance-ı prototipdən tutmuş milyonlarla istifadəçisi olan enterprise tətbiqlərə qədər istənilən layihə üçün ideal seçim edir. Yeganə xərc mədəsi Performance SDK məlumatlarının çıxış trafikidir, lakin bu, tətbiqin digər şəbəkə əməliyyatları ilə müqayisədə çox azdır (cihaz başına ayda 1 MB-dan az). BigQuery export-da saxlama və sorğular üçün ödəniş tətbiq olunur, lakin Performance SDK-nın özü pulsuzdur.

Avtomatik metrikalar: kod olmadan nə ölçülür

Firebase Performance heç bir kod sətri olmadan avtomatik olaraq beş kateqoriya metrika toplayır: tətbiqin başlanma vaxtı (app start), yavaş sorğular (slow HTTP requests), ekran render sürəti (screen rendering), yaddaş istifadəsi (memory usage, yalnız Android) və kadr tezliyi (frame rate, yalnız Android). Bu metrikalar SDK qoşulduqdan və ilk istifadəçi sessiyasından sonra Firebase konsolunda dərhal mövcud olur.

App Start Time — prosesin başlamasından UI-nın qarşılıqlı əlaqəyə tam hazır olmasına qədər olan vaxt. Soyuq başlanma (tətbiq sıfırdan başlayır) və isti başlanma (tətbiq fon vəziyyətindən bərpa olunur) olaraq bölünür. Soyuq başlanma DEX fayllarının yüklənməsini, statik sahələrin işə salınmasını, Application.onCreate və Activity.onCreate çağırışlarını əhatə edir. Firebase avtomatik olaraq başlanma növünü təsnif edir və hər növ üçün vaxt paylanmasını göstərir.

Screen Rendering Time — ekranın yüklənməsinin başlamasından (Android üçün onCreate, iOS üçün viewDidLoad) ekranın qarşılıqlı əlaqəyə hazır olmasına qədər olan vaxt (onResume, viewDidAppear). Firebase hər ekran üçün məlumatları aqreqasiya edir (sinif adı və ya custom screen name üzrə), hansı ekranın ən uzun yükləndiyini müəyyən etməyə imkan verir. Android üçün əlavə olaraq dropped frames ölçülür — ekran renderi zamanı buraxılmış kadrların sayı (jank).

Şəbəkə sorğuları (HTTP/HTTPS)

Performance SDK URLSession, OkHttp və ya URLConnection vasitəsilə tətbiqdən göndərilən hər HTTP/HTTPS sorğusunu avtomatik olaraq ələ keçirir və ölçür. Hər sorğu üçün qeyd olunur: URL (təhlükəsizlik üçün query parametrləri olmadan yol), HTTP metodu, cavab kodu, baytlarla cavab ölçüsü, sorğunun müddəti və əlaqə sürəti (WiFi, Cellular). Məlumatlar Firebase konsolunun „Network Requests” panelində aqreqasiya edilir.

Slow Requests — müddəti müəyyən edilmiş həddi aşan sorğular. Standart „yavaş sorğu” həddi 4000 ms-dədir. Bu metrika server hissəsi ilə bağlı problemləri aşkarlamaq üçün kritik əhəmiyyət daşıyır: backend yenilənməsindən sonra yavaş sorğuların sayı 1%-dən 15%-ə yüksələrsə, bu, server loqlarının dərhal təhlili üçün siqnaldır. İstifadəçilər 5 saniyədən çox cavab gözləməyəcək — Firebase məlumatları göstərir ki, sorğu 3 saniyədən çox çəkərsə, istifadəçilərin 53%-i tətbiqi bağlayır.

Avtomatik instrumentasiyanın məhdudiyyətləri

iOS məhdudiyyətləri: iOS-da Performance SDK dropped frames ölçə bilməz (bu özəl APİ-dir). iOS-da jank ölçmək üçün MetricKit və ya CADisplayLink istifadə edin. Həmçinin iOS-da SDK URLSession istifadə etməyən üçüncü tərəf HTTP kliyentləri (məsələn, SwiftNIO) vasitəsilə yerinə yetirilən sorğuları ələ keçirmir. Belə hallar üçün HTTP atributları ilə fərdi izlərdən istifadə edin.

Android məhdudiyyətləri: Android-də avtomatik yaddaş ölçümü yalnız Android 8.0+ (API 26+) olan cihazlarda mövcuddur. Köhnə versiyalar üçün Debug.getMemoryInfo() vasitəsilə məlumatların alınması ilə fərdi izlərdən istifadə edin. SDK həmçinin WebSocket əlaqələrini ələ keçirmir — onlar üçün ayrı izlər tələb olunur. Məhdudiyyətlərə baxmayaraq, avtomatik metrikalar performans monitorinqi ehtiyaclarının 80%-ni əhatə edir.

Fərdi izlər və HTTP atributları

Fərdi izlər (custom traces) — tərtibatçının müəyyən ssenarilərin performansını ölçmək üçün əl ilə yaratdığı adlandırılmış vaxt intervallarıdır: xəbər lentinin yüklənməsi, şəkil emalı, məlumat sinxronizasiyası, mürəkkəb verilənlər bazası sorğusunun yerinə yetirilməsi. Fərdi izlər avtomatik metrikaları tamamlayır və tərtibatçının performans üçün kritik hesab etdiyi kod hissələrini ölçməyə imkan verir.

Hər bir izin adı (maksimum 100 simvol) və iz daxilində qeyd olunan 5-ə qədər fərdi metrikası (metrics) ola bilər. Məsələn, „image_processing” izində „original_file_size” və „processed_file_size” metrikalarını ölçmək olar. Metrikalar Firebase konsolunda paylanmalar (min, max, average, persentillər) şəklində göstərilir ki, bu da yalnız müddəti deyil, həm də əməliyyatın xarakteristikasını təhlil etməyə imkan verir.

HTTP atributları — SDK tərəfindən avtomatik ələ keçirilməyən şəbəkə sorğuları (məsələn, WebSocket və ya üçüncü tərəf kitabxanalar vasitəsilə) üçün xüsusi fərdi izlər növüdür. HTTP atributları URL, HTTP metodu, cavab kodu və cavab ölçüsünü əhatə edir. Firebase onları „Network Requests” bölməsində avtomatik toplanmış sorğularla birlikdə göstərərək şəbəkə qarşılıqlı əlaqəsinin vahid şəklini təmin edir.

Fərdi izlərdən nə vaxt istifadə etməli

Fərdi izlər aşağıdakıları ölçmək üçün əvəzolunmazdır: yerli verilənlər bazasından (Room, CoreData) məlumat yükləmə vaxtı, mürəkkəb hesablamaların müddəti (şifrələmə, sıxışdırma), animasiya və keçid performansı, üçüncü tərəf SDK-larının cavab müddəti (xəritələr, ödənişlər, analitika). Hər belə ssenari üçün bir iz yaradın, ölçülən kodu start/stop ilə əhatə edin və sonrakı seqmentasiya üçün atributlar əlavə edin.

Fərdi izlərdən sui-istifadə etməyin. Hər bir iz əlavə batareya və trafik sərfindir. İstehsal versiyasında 10–15 aktiv izdən çox olmamaq tövsiyə olunur. Debug üçün daha çox iz əlavə etmək olar, lakin buraxılışdan əvvəl Remote Config vasitəsilə artıq olanları söndürün (performance_tracing_enabled flagindan istifadə edin). Bu, yalnız seçilmiş istifadəçilər və ya sessiyalar üçün ətraflı izləməni aktivləşdirməyə imkan verir.

Seqmentasiya üçün iz atributları

Fərdi atributlar (custom attributes) — Firebase konsolunda sonrakı filtrləmə üçün izə əlavə edilə bilən açar-dəyər cütləridir. Məsələn, „feed_load” izinə „feed_type” (main, explore, following) və „cache_status” (cold, warm) atributlarını əlavə etmək olar. Konsolda iz məlumatlarını bu atributlar üzrə filtrləyərək hansı lent növünün ən yavaş yükləndiyini müəyyən etmək olar.

Məhdudiyyətlər: hər bir izin 5-ə qədər fərdi atributu ola bilər. Atribut dəyəri 100 simvola qədər olan sətirdir. Atributlar iz başlamazdan əvvəl təyin edilməlidir; başlandıqdan sonra atributun dəyişdirilməsi nəzərə alınmır. Bu məhdudiyyət performansla bağlıdır: başlandıqdan sonra atributların təyin edilməsi əlavə sinxronizasiya tələb edərdi.

Performans həddləri və xəbərdarlıqlar

Həddlər (thresholds) — Firebase Performance-ın aşıldıqda xəbərdarlıq yaratdığı konfiqurasiya edilə bilən metrik sərhəd dəyərləridir. Həddlər Firebase konsolunda (Performance > Thresholds bölməsi) hər avtomatik metrika üçün müəyyən edilir: app start time (cold/warm), screen rendering time, slow HTTP requests, HTTP response time. Tətbiqin bütün versiyaları üçün qlobal və ya müəyyən versiyalar üçün xüsusi həddlər təyin etmək olar.

Xəbərdarlıqlar (alerts) — hədd aşıldıqda Firebase-in göndərdiyi avtomatik bildirişlərdir. Xəbərdarlıqlar email, Slack webhook, PagerDuty və ya Cloud Functions (üçün fərdi emal) üçün konfiqurasiya edilə bilər. Hər bir xəbərdarlıqda: metrika adı, cari dəyər, hədd dəyəri, tətbiq versiyası, seqment (cihaz, ölkə) var. Xəbərdarlıqlar istifadəçilərə görünməzdən əvvəl performans deqradasiyasına reaksiya verməyə imkan verir.

Tövsiyə olunan həddlər sənaye standartına görə (Google I/O 2025): soyuq başlanma — 2 saniyədən az, isti başlanma — 1 saniyədən az, ekran renderi — 500 ms-dən az, HTTP sorğu müddəti — 3000 ms-dən az (95-ci persentil), yavaş sorğuların payı — 5%-dən az. Yüksək rəqabətli tətbiqlər (Social, E-commerce) üçün hədəf həddlər daha sərt ola bilər: soyuq başlanma < 1.5 saniyə, HTTP < 1000 ms.

Firebase konsolunda həddlərin konfiqurasiyası

Firebase konsolunda Performance bölməsinə keçin, Thresholds vərəqini açın. Hər metrika üçün istənilən hədd dəyərini və aşılmanın təsir etməli olduğu istifadəçi faizini təyin edin. Məsələn: „soyuq başlanmanı yavaş hesab edirik, əgər istifadəçilərin 10%-dən çoxu üçün 2 saniyədən çox çəkərsə”. Firebase cari metrika dəyərlərini və aşılma tarixçəsini göstərərək realisitk həddlərin seçilməsinə kömək edir.

Vacib: həddlər məlumat toplanmasına təsir etmir, onlar yalnız bildirişlərin yaradılmasını idarə edir. Hədd çox aşağı olarsa (məsələn, soyuq başlanma 1 saniyə, halbuki cihazların 50%-i 3 saniyədə başlayır), xəbərdarlıqlar daim gələcək və tərtibatçıların görmədiyi „səs-küçə” çevriləcək. Həddləri cari göstəricilər əsasında təyin edin, sonra tətbiq optimallaşdırıldıqca tədricən sərtləşdirin.

Firebase konsolunda Performance Dashboard

Performance Dashboard əsas metrikaları tətbiq versiyası, cihaz, ölkə, əlaqə növü və OS versiyası üzrə bölünmə ilə vaxt seriyaları şəklində göstərir. Hər metrika üçün mövcuddur: orta dəyər, median, 95-ci persentil, 99-cu persentil. 95-ci persentil performansı qiymətləndirmək üçün ən informativ metrikadır, çünki o, kənar dəyərləri nəzərə almadan tətbiqin „zəif cihazlarda” necə işlədiyini göstərir.

Dashboard versiya müqayisəsini dəstəkləyir: metrikaların vizual müqayisəsi üçün iki tətbiq versiyasını (cari və əvvəlki) seçin. Yenilənmədən sonra 95-ci persentil başlanma vaxtı 2.1-dən 3.4 saniyəyə yüksələrsə — reqressiya aşkardır və yavaşlamaya səbəb olan commiti tapmaq lazımdır. Firebase Performance GitHub, GitLab və Bitbucket ilə inteqrasiya edir ki, bu da metrika dəyişikliklərini konkret commitlər ilə əlaqələndirməyə imkan verir.

Performance Monitoring üçün kod nümunələri

Kotlin dilində Android tətbiqində Firebase Performance Monitoring-in inteqrasiya nümunələrini nəzərdən keçirək. Kod xəbər lentinin yüklənməsini ölçmək üçün fərdi iz yaratmağı, avtomatik ələ keçirilməyən sorğu üçün HTTP atributu əlavə etməyi və şəkil emal vaxtını ölçmək üçün Trace istifadəsini nümayiş etdirir. Bütün nümunələr Remote Config vasitəsilə izləməni söndürmə imkanını nəzərdə tutur.

İstifadədən əvvəl asılılığı əlavə edin: implementation("com.google.firebase:firebase-perf") Firebase BOM vasitəsilə. Avtomatik instrumentasiya üçün əlavə konfiqurasiya tələb olunmur — SDK asılılıq qoşulduqdan sonra standart əməliyyatları avtomatik ələ keçirir.

Lent yüklənməsi üçün fərdi iz

Birinci nümunə — serverdən xəbər lentinin yüklənmə vaxtının ölçülməsi. İz şəbəkədən məlumat alan və JSON parse edən asinxron fetchFeed əməliyyatını əhatə edir. İzə fərdi atributlar əlavə edilmişdir: məlumat mənbəyi (cache və ya network) və alınan postların sayı. Bu, məlumatları seqmentləşdirməyə və lentin hansı şəraitdə ən uzun yükləndiyini anlamağa imkan verir.

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

loadFeedWithTrace funksiyası iz atributu kimi istifadə olunan source („cache” və ya „network”) parametrini qəbul edir. Asinxron əməliyyat tamamlandıqdan sonra iz finally blokunda dayandırılır ki, bu da istisna zamanı belə dayanmanı təmin edir. items_count metrikası postların sayının yüklənmə vaxtına necə təsir etdiyini təhlil etməyə imkan verir. Firebase konsolunda izləri source atributu üzrə filtrləyərək şəbəkədən yüklənmənin keşdən 3 dəfə yavaş olduğunu görmək olar.

Qeyri-standart sorğu üçün HTTP atributu

İkinci nümunə — WebSocket vasitəsilə yerinə yetirilən sorğu üçün HTTP atributu (avtomatik ələ keçirilmir). URL sorğusunu, onun metodunu, cavab kodunu və ölçüsünü əl ilə qeyd etməyə imkan verən HttpMetric sinfi istifadə olunur. Firebase bu sorğunu Network Requests bölməsində avtomatik ələ keçirilənlərlə birlikdə göstərəcək.

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

Nümunədə sendWithHttpMetric qeyri-standart HTTP çağırışını qeydiyyatdan keçirmək üçün newHttpMetric istifadə edir. SDK onu avtomatik ələ keçirmir, buna görə tərtibatçı əl ilə URL, metod, cavab kodu və ölçüləri təyin edir. URL-i query parametrləri olmadan təyin etmək vacibdir (təhlükəsizlik və aqreqasiya üçün) — yəni /data, /data?token=abc deyil. Firebase avtomatik olaraq eyni URL şablonlarını qruplaşdırır.

Şəkil emal vaxtının ölçülməsi

Üçüncü nümunə fərdi izdən istifadə edərək şəkil emal vaxtının (sıxışdırma, ölçü dəyişikliyi) ölçülməsini nümayiş etdirir. Bu halda iz sinxron əməliyyatı əhatə edir, lakin istehsal üçün UI axınını bloklamamaq üçün korutinlər və ya RxJava istifadə edin.

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
}

compressImage funksiyası şəklin 80% keyfiyyətlə JPEG-ə sıxışdırma vaxtını ölçür. format atributu gələcəkdə JPEG vs WebP sıxışdırma vaxtlarını müqayisə etməyə imkan verir. output_size_kb metrikası sıxışdırmanın nə qədər effektiv olduğunu göstərir. Firebase konsolunda paylanmanı görmək olar: zəif cihazlarda (büdcə Android) sıxışdırma flaqmanlardan 4 dəfə çox vaxt aparır ki, bu da şəkillərin serverə göndərilməsində gecikmələrə səbəb ola bilər.

Məlumatlar əsasında performansı necə yaxşılaşdırmaq olar

Firebase Performance məlumatları təqdim edir, lakin hazır həllər vermir. Metrikaların təhlili hər metrika üçün performans deqradasiyasının tipik səbəblərinin başa düşülməsini tələb edir. Əsas pisləşmə modellərinə və Performance Monitoring məlumatları əsasında onların diaqnostika üsullarına baxaq. Yanaşma: metrikada anomaliya tapın → tipik səbəbləri yoxlayın → optimallaşdırma tətbiq edin → bir həftə sonra nəticəni yoxlayın.

Yavaş soyuq başlanma (> 2 saniyə): səbəblər — Application.onCreate-də SDK-ların ağır işə salınması (analitika, crash reporting, map SDK), böyük resursların yüklənməsi (şriftlər, temalar), başlanma zamanı əsas axında sinxron əməliyyatlar. Həllər: SDK-ların tənbəl işə salınması, resursların gecikmiş yüklənməsi, işə salma zamanı placeholder göstərmək üçün SplashScreen API (Android 12+) istifadəsi. Firebase Performance tətbiqin hansı versiyasının daha yavaş başladığını göstərəcək — hansı asılılıqların əlavə edildiyini və ya yeniləndiyini yoxlayın.

Yavaş ekran renderi (> 500 ms): səbbəblər — mürəkkəb View iyerarxiyası (iç-içə ConstraintLayout, çoxlu Fragment), UI axınında məlumat yüklənməsi (şəbəkə və ya disk), ağır draw əməliyyatları (böyük şəkillər, fərdi View). Həllər: layout iyerarxiyasının optimallaşdırılması (Android Studio-da Layout Inspector), məlumatların fon axınına köçürülməsi, Glide və ya Coil vasitəsilə şəkillərin keşlənməsi. Ən yavaş ekranı tapmaq və onu ilk növbədə optimallaşdırmaq üçün Firebase-də Screen Rendering filtrindən istifadə edin.

Şəbəkə sorğularının optimallaşdırılması

Yavaş HTTP sorğuları (> 3 saniyə): səbəblər — yavaş server, böyük payloadlar, keşin olmaması, optimal olmayan protokol (HTTP/2 əvəzinə HTTP/1.1), DNS həlli. Həllər: server tərəfini yoxlayın (uptime, latency), cavab ölçüsünü azaldın (paginasiya, GraphQL, JSON əvəzinə protobuf), HTTP başlıqları (Cache-Control) vasitəsilə keşi aktivləşdirin, timeout və təkrarlama məntiqi əlavə etmək üçün OkHttp Interceptor istifadə edin.

Firebase Performance sorğunun vaxt paylanmasını göstərir: DNS həlli, TCP əl sıxma, TLS əl sıxma, sorğunun göndərilməsi, cavabın qəbulu. Vaxtın çoxu DNS-ə düşərsə — DNS ön yüklənməsindən istifadə edin (OkHttp DNS-over-HTTPS). TLS-ə düşərsə — session resumption və cipher suites tənzimləməsindən istifadə edin. Cavab qəbuluna düşərsə — cavab ölçüsünü və istifadəçinin şəbəkə sürətini yoxlayın. Firebase məlumatları yalnız „sorğu yavaşdır” demək deyil, protokol səviyyəsində problemi lokallaşdırmağa imkan verir.

İzləməni söndürmək üçün Remote Config inteqrasiyası

İstehsal üçün fərdi izləri uzaqdan söndürməyə imkan verən performance_tracing_enabled Remote Config flagi əlavə etmək tövsiyə olunur. Firebase Performance SDK kliyentdə çox məlumat yaradırsa və ya performansa təsir edirsə (zəif cihazlarda), minimal yükü olan yalnız avtomatik metrikaları buraxaraq bütün istifadəçilər üçün izləri söndürmək olar.

Məntiq nümunəsi: tətbiq başladıqda Remote Config parametrini yoxlayın performance_tracing_enabled. False olarsa, bütün Firebase.performance.newTrace() çağırışları məlumat toplamayan stub obyekti qaytarır. Bu, iz yaratmazdan əvvəl flagi yoxlayan wrapper sinfi vasitəsilə həyata keçirilir. Belə yanaşma bütün auditoriyaya təsir etmədən müəyyən istifadəçilər (beta testçilər, tərtibatçılar) üçün ətraflı izləməni aktivləşdirməyə imkan verir.