Firebase Performance: Nedir, Metrikler ve Nasıl Takip Edilir

Firebase Performance Monitoring Nedir

Firebase Performance Monitoring, mobil uygulama performans metriklerini toplamak, birleştirmek ve görselleştirmek için bir SDK ve bulut platformudur. SDK uygulamaya gömülür ve otomatik olarak önemli noktaları enstrümante eder: Activity yaşam döngüsü (Android) veya ViewController (iOS), URLSession (iOS) veya OkHttp (Android) üzerinden ağ istekleri ve sistem çağrıları. Toplanan veriler Firebase sunucusuna gönderilir ve burada uygulama sürümü, cihaz, ülke ve diğer özelliklere göre birleştirilir.

Performance SDK mimarisi, minimum ek yük ilkesi üzerine kurulmuştur: enstrümantasyon, ölçülen işlemlerin yürütme süresine %1–2'den fazla eklemez. Veriler asenkron olarak toplanır ve gönderilmeden önce cihazda arabelleğe alınır, böylece UI iş parçacığı performansı üzerindeki herhangi bir etki ortadan kaldırılır. Veriler bir programa göre (varsayılan olarak her 30 dakikada bir) veya arabellek 100 KB'a ulaştığında gönderilir.

Firebase Performance ile Android Studio profilleyicileri (CPU Profiler) veya Xcode Instruments arasındaki temel fark, üretim izlemesidir. Firebase Performance, yalnızca geliştirici cihazlarından değil, gerçek kullanıcı cihazlarından veri toplar. Bu, yalnızca belirli modellerde, işletim sistemi sürümlerinde veya belirli bölgelerde meydana gelen sorunları — kontrollü bir ortamda tekrarlanamayan sorunları — tespit etmeyi sağlar.

SDK, Kod Değişikliği Olmadan Verileri Nasıl Toplar

Otomatik enstrümantasyon, Firebase Performance'ın ana özelliğidir. Android için SDK otomatik olarak ActivityLifecycleCallbacks'i kaydeder ve onCreate ile onResume arasındaki süreyi (ekran oluşturma süresi) ölçer. iOS için viewDidLoad ve viewDidAppear yöntemlerini swizzle eder. Ağ istekleri OkHttpInterceptor (Android) veya NSURLProtocol (iOS) düzeyinde kesilir. Geliştiricinin standart metrikler için start/stop çağrıları eklemesi gerekmez.

Performance SDK'yı etkinleştirme ve devre dışı bırakma, Google Services eklentisi (Android) veya Info.plist (iOS) aracılığıyla yönetilir. Hata ayıklama için, hangi metriklerin toplandığını ve gönderildiğini gösteren Performance SDK'nın ayrıntılı günlük kaydını etkinleştirebilirsiniz. Üretimde, günlüklerin gereksiz bilgilerle dolmasını önlemek için günlük kaydını uyarı düzeyinde tutmanız önerilir. Flutter veya React Native projelerinde otomatik enstrümantasyon sınırlı olabilir — daha fazla ayrıntı için kod örnekleri bölümüne bakın.

Ücretsiz Sınırlar ve Fiyatlandırma

Firebase Performance, izleme sayısı veya veri hacmi konusunda herhangi bir sınırlama olmaksızın ücretsiz Spark katmanında kullanılabilir. Ücretli Blaze katmanı da Performance Monitoring için ücret talep etmez — her iki katmanda da tamamen ücretsiz olan birkaç Firebase hizmetinden biridir. Yalnızca bir sınırlama vardır: veriler 30 gün (Spark'ta) ve 365 güne kadar (Blaze'de) saklanır. Uzun vadeli analiz için verileri BigQuery dışa aktarımı yoluyla dışa aktarın.

Ücretsiz olması, Firebase Performance'ı prototipten milyonlarca kullanıcılı kurumsal uygulamaya kadar her proje için ideal bir seçim haline getirir. Tek gider, Performance SDK'nın giden trafiğidir, ancak uygulamanın diğer ağ işlemlerine kıyasla ihmal edilebilir düzeydedir (cihaz başına ayda 1 MB'tan az). BigQuery dışa aktarımı depolama ve sorgular için ücret talep eder, ancak Performance SDK'nın kendisi ücretsizdir.

Otomatik Metrikler: Kod Olmadan Neler Ölçülür

Firebase Performance, tek bir kod satırı olmadan beş metrik kategorisini otomatik olarak toplar: uygulama başlatma süresi, yavaş HTTP istekleri, ekran oluşturma hızı, bellek kullanımı (yalnızca Android) ve kare hızı (yalnızca Android). Bu metrikler, SDK bağlandıktan ve ilk kullanıcı oturumundan hemen sonra Firebase konsolunda kullanılabilir.

Uygulama Başlatma Süresi — işlem başlatmasından kullanıcı arayüzünün etkileşim için tamamen hazır olmasına kadar geçen süredir. Soğuk başlatma (uygulama sıfırdan başlar) ve sıcak başlatma (uygulama arka plan durumundan devam eder) olarak ikiye ayrılır. Soğuk başlatma, DEX dosyalarının yüklenmesini, statik alanların başlatılmasını, Application.onCreate ve Activity.onCreate çağrısını içerir. Firebase otomatik olarak başlatma türünü sınıflandırır ve her tür için zaman dağılımını gösterir.

Ekran Oluşturma Süresi — ekran yüklemesinin başlamasından (Android için onCreate, iOS için viewDidLoad) ekranın etkileşime hazır olduğu ana (onResume, viewDidAppear) kadar geçen süredir. Firebase, verileri her ekrana (sınıf adına veya özel ekran adına göre) göre birleştirir ve hangi ekranın en uzun süre yüklendiğini belirlemeyi sağlar. Android için, düşürülen kareler de ölçülür — ekran oluşturma sırasında atlanan kare sayısı (jank).

Ağ İstekleri (HTTP/HTTPS)

Performance SDK, URLSession, OkHttp veya URLConnection aracılığıyla uygulamadan gönderilen her HTTP/HTTPS isteğini otomatik olarak keser ve ölçer. Her istek için şunlar kaydedilir: URL (güvenlik için sorgu parametreleri olmadan yol), HTTP yöntemi, yanıt kodu, bayt cinsinden yanıt boyutu, istek süresi ve bağlantı hızı (WiFi, Hücresel). Veriler, Firebase konsolunun Ağ İstekleri panosunda birleştirilir.

Yavaş İstekler — süresi belirlenen bir eşiği aşan isteklerdir. Varsayılan olarak, yavaş istek eşiği 4000 ms'dir. Bu metrik, arka uç sorunlarını belirlemek için kritik öneme sahiptir: bir arka uç güncellemesinden sonra yavaş isteklerin sayısı %1'den %15'e yükselirse, bu derhal sunucu günlüklerinin analiz edilmesi gerektiğinin bir işaretidir. Kullanıcılar bir yanıt için 5 saniyeden fazla beklemeyecektir — Firebase verileri, bir istek 3 saniyeden uzun sürerse kullanıcıların %53'ünün uygulamayı kapattığını gösterir.

Otomatik Enstrümantasyonun Sınırlamaları

iOS Sınırlamaları: iOS'ta, Performance SDK düşürülen kareleri ölçemez (bu özel bir API'dir). iOS'ta jank'ı ölçmek için MetricKit veya CADisplayLink kullanın. Ayrıca, iOS'ta SDK, URLSession kullanmayan üçüncü taraf HTTP istemcileri (SwiftNIO gibi) aracılığıyla gerçekleştirilen istekleri kesmez. Bu gibi durumlarda, HTTP nitelikleriyle özel izlemeler kullanın.

Android Sınırlamaları: Android'de, otomatik bellek ölçümü yalnızca Android 8.0+ (API 26+) cihazlarda kullanılabilir. Eski sürümler için, Debug.getMemoryInfo() aracılığıyla elde edilen verilerle özel izlemeler kullanın. Ayrıca, SDK WebSocket bağlantılarını kesmez — bunlar ayrı izlemeler gerektirir. Bu sınırlamalara rağmen, otomatik metrikler performans izleme ihtiyaçlarının %80'ini karşılar.

Özel İzlemeler ve HTTP Nitelikleri

Özel izlemeler (custom traces), geliştiricinin belirli senaryoların (haber beslemesi yükleme, görüntü işleme, veri senkronizasyonu, karmaşık veritabanı sorgusu yürütme) performansını ölçmek için manuel olarak oluşturduğu adlandırılmış zaman aralıklarıdır. Özel izlemeler, otomatik metrikleri tamamlar ve geliştiricinin performans için kritik olduğunu düşündüğü kod bölümlerini tam olarak ölçmeye olanak tanır.

Her izlemenin bir adı (en fazla 100 karakter) vardır ve en fazla 5 özel metrik (izleme içinde kaydedilen sayısal değerler) içerebilir. Örneğin, bir "image_processing" izlemesinde "original_file_size" ve "processed_file_size" gibi metrikleri ölçebilirsiniz. Metrikler, Firebase konsolunda dağılımlar (min, maks, ortalama, yüzdelik dilimler) olarak görüntülenir ve yalnızca süreyi değil, işlem özelliklerini de analiz etmeye olanak tanır.

HTTP Nitelikleri — SDK tarafından otomatik olarak kesilmeyen ağ istekleri için özel bir izleme türüdür (WebSocket veya üçüncü taraf kitaplıklar aracılığıyla). HTTP nitelikleri URL, HTTP yöntemi, yanıt kodu ve yanıt boyutunu içerir. Firebase, bunları otomatik olarak toplanan isteklerle birlikte Ağ İstekleri bölümünde görüntüleyerek ağ etkileşiminin birleşik bir resmini sağlar.

Özel İzlemeler Ne Zaman Kullanılmalı

Özel izlemeler şunları ölçmek için vazgeçilmezdir: yerel veritabanından (Room, CoreData) veri yükleme süresi, karmaşık hesaplamaların süresi (şifreleme, sıkıştırma), animasyon ve geçiş performansı, üçüncü taraf SDK'ların (haritalar, ödemeler, analiz) yanıt süresi. Bu tür her senaryo için bir izleme oluşturun, ölçülecek kodu start/stop ile sarın ve sonraki bölümleme için nitelikler ekleyin.

Özel izlemeleri kötüye kullanmayın. Her izleme, ek pil ve trafik yükü ekler. Üretim sürümünde 10–15'ten fazla aktif izleme olmaması önerilir. Hata ayıklama için daha fazla izleme ekleyebilirsiniz, ancak yayınlamadan önce Remote Config aracılığıyla aşırı izlemeleri devre dışı bırakın (performance_tracing_enabled bayrağını kullanın). Bu, yalnızca seçili kullanıcılar veya oturumlar için ayrıntılı izlemeyi etkinleştirmeye olanak tanır.

Bölümleme İçin İzleme Nitelikleri

Özel nitelikler, Firebase konsolunda daha sonra filtreleme için bir izlemeye eklenebilen anahtar-değer çiftleridir. Örneğin, "feed_load" izlemesi için "feed_type" (main, explore, following) ve "cache_status" (cold, warm) gibi nitelikler ekleyebilirsiniz. Konsolda, izleme verileri bu niteliklere göre filtrelenerek hangi besleme türünün en yavaş yüklendiği belirlenebilir.

Sınırlamalar: her izleme en fazla 5 özel niteliğe sahip olabilir. Nitelik değerleri en fazla 100 karakterlik dizelerdir. Nitelikler izleme başlamadan önce ayarlanmalıdır; başladıktan sonra bir niteliği değiştirmek yok sayılır. Bu sınırlama performansla ilgilidir — başladıktan sonra nitelikleri sabitlemek ek senkronizasyon gerektirir.

Performans Eşikleri ve Uyarılar

Eşikler, metrikler için yapılandırılabilir sınır değerleridir ve aşıldığında Firebase Performance bir uyarı oluşturur. Eşikler, her otomatik metrik için Firebase konsolunda (Performance > Thresholds) ayarlanır: uygulama başlatma süresi (soğuk/sıcak), ekran oluşturma süresi, yavaş HTTP istekleri, HTTP yanıt süresi. Tüm uygulama sürümleri için genel eşikler veya belirli sürümler için özel eşikler ayarlayabilirsiniz.

Uyarılar, bir eşik aşıldığında Firebase'in gönderdiği otomatik bildirimlerdir. Uyarılar e-posta, Slack webhook, PagerDuty veya Cloud Functions (özel işleme için) aracılığıyla yapılandırılabilir. Her uyarı şunları içerir: metrik adı, geçerli değer, eşik değeri, uygulama sürümü, bölüm (cihaz, ülke). Uyarılar, performans bozulması kullanıcılar tarafından fark edilmeden önce yanıt vermeyi sağlar.

Önerilen eşikler sektör standardına (Google I/O 2025) göre: soğuk başlatma — 2 saniyeden az, sıcak başlatma — 1 saniyeden az, ekran oluşturma — 500 ms'den az, HTTP istek süresi — 3000 ms'den az (%95'inci yüzdelik dilim), yavaş istek oranı — %5'ten az. Yüksek rekabetin olduğu uygulamalar (Sosyal, E-ticaret) için hedef eşikler daha katı olabilir: soğuk başlatma < 1,5 saniye, HTTP < 1000 ms.

Firebase Konsolunda Eşikleri Ayarlama

Firebase konsolunda, Performance bölümüne gidin, Thresholds sekmesini açın. Her metrik için istenen eşik değerini ve aşımdan etkilenmesi gereken kullanıcı yüzdesini ayarlayın. Örneğin: "Kullanıcıların %10'undan fazlası için 2 saniyeyi aşarsa soğuk başlatmayı yavaş olarak kabul et". Firebase, gerçekçi eşikler seçmeye yardımcı olmak için geçerli metrik değerlerini ve aşım geçmişini gösterecektir.

Önemli: eşikler veri toplamayı etkilemez, yalnızca bildirim oluşturmayı kontrol eder. Eşik çok düşükse (örneğin, cihazların %50'si 3 saniyede başlarken soğuk başlatma 1 saniye), uyarılar sürekli olarak gelecek ve geliştiricilerin fark etmeyi bırakacağı "gürültü" haline gelecektir. Eşikleri mevcut performansa göre ayarlayın, ardından uygulamayı optimize ettikçe kademeli olarak sıkılaştırın.

Firebase Konsolunda Performans Panosu

Performans panosu, temel metrikleri uygulama sürümü, cihaz, ülke, bağlantı türü ve işletim sistemi sürümüne göre ayrılmış zaman serileri olarak görüntüler. Her metrik için şunlar mevcuttur: ortalama, medyan, %95'inci yüzdelik dilim, %99'uncu yüzdelik dilim. %95'inci yüzdelik dilim, performans değerlendirmesi için en bilgilendirici metriktir çünkü aykırı değerleri göz ardı ederek uygulamanın zayıf cihazlarda nasıl çalıştığını gösterir.

Pano, sürüm karşılaştırmasını destekler: metriklerin görsel karşılaştırması için iki uygulama sürümü (mevcut ve önceki) seçin. Bir güncellemeden sonra %95'inci yüzdelik dilim başlatma süresi 2,1 saniyeden 3,4 saniyeye yükseldiyse — gerileme açıktır ve yavaşlamaya neden olan commit'i bulmanız gerekir. Firebase Performance, GitHub, GitLab ve Bitbucket ile entegre olur ve metrik değişikliklerinin belirli commit'lerle ilişkilendirilmesine olanak tanır.

Performans İzleme için Kod Örnekleri

Kotlin kullanan bir Android uygulamasında Firebase Performance Monitoring entegrasyon örneklerine bakalım. Kod, haber beslemesi yüklemeyi ölçmek için özel bir izleme oluşturmayı, otomatik olarak kesilmeyen bir istek için HTTP niteliği eklemeyi ve görüntü işleme süresini ölçmek için Trace kullanımını gösterir. Tüm örnekler, Remote Config aracılığıyla izlemeyi devre dışı bırakma yeteneğini dikkate alır.

Kullanmadan önce bağımlılığı ekleyin: implementation("com.google.firebase:firebase-perf") Firebase BOM aracılığıyla. Otomatik enstrümantasyon için ek bir kurulum gerekmez — bağımlılık eklendikten sonra SDK otomatik olarak standart işlemleri keser.

Besleme Yükleme İçin Özel İzleme

İlk örnek — sunucudan haber beslemesinin yükleme süresini ölçme. İzleme, ağdan veri alan ve JSON ayrıştıran asenkron fetchFeed işlemini sarar. İzlemeye özel nitelikler eklenmiştir: veri kaynağı (cache veya network) ve alınan gönderi sayısı. Bu, verileri bölümlemeye ve beslemenin hangi koşullarda en yavaş yüklendiğini anlamaya olanak tanır.

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 işlevi, izleme niteliği olarak kullanılan bir source parametresi ("cache" veya "network") alır. Asenkron işlem tamamlandıktan sonra izleme bir finally bloğunda durur ve istisna durumunda bile durmayı garanti eder. items_count metriği, gönderi sayısının yükleme süresini nasıl etkilediğini analiz etmeye olanak tanır. Firebase konsolunda, source niteliğine göre izlemeleri filtreleyebilir ve ağ yüklemesinin önbellekten 3 kat daha yavaş olduğunu görebilirsiniz.

Standart Olmayan İstek İçin HTTP Niteliği

İkinci örnek — WebSocket aracılığıyla gerçekleştirilen bir istek için HTTP niteliği (otomatik olarak kesilmez). Bir URL isteğini, yöntemini, yanıt kodunu ve boyutunu manuel olarak kaydetmeye olanak tanıyan HttpMetric sınıfı kullanılır. Firebase, bu isteği otomatik olarak kesilen isteklerle birlikte Ağ İstekleri bölümünde görüntüler.

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

Örnekte, sendWithHttpMetric, standart olmayan bir HTTP çağrısını kaydetmek için newHttpMetric kullanır. SDK bunu otomatik olarak kesmez, bu nedenle geliştirici URL'yi, yöntemi, yanıt kodunu ve boyutları manuel olarak ayarlar. URL'yi sorgu parametreleri olmadan ayarlamak önemlidir (güvenlik ve birleştirme için) — yani /data?token=abc değil, /data. Firebase otomatik olarak aynı URL desenlerini gruplar.

Görüntü İşleme Süresini Ölçme

Üçüncü örnek, özel bir izleme kullanarak görüntü işlemenin (sıkıştırma, yeniden boyutlandırma) süresini ölçmeyi gösterir. Bu durumda izleme, senkron bir işlemi sarar, ancak üretim için UI iş parçacığını bloke etmemek için coroutines veya RxJava kullanın.

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 işlevi, %80 kalitede JPEG görüntü sıkıştırma süresini ölçer. format niteliği, gelecekte JPEG ve WebP sıkıştırma süresini karşılaştırmaya olanak tanır. output_size_kb metriği, sıkıştırmanın ne kadar verimli olduğunu gösterir. Firebase konsolunda dağılımı görebilirsiniz: zayıf cihazlarda (bütçe Android), sıkıştırma amiral gemilerine göre 4 kat daha uzun sürer ve bu, sunucuya görüntü yüklerken gecikmelere neden olabilir.

Verilere Dayalı Performans Nasıl İyileştirilir

Firebase Performance veri sağlar ancak hazır çözümler sunmaz. Metriklerin analizi, her metrik için performans bozulmasının tipik nedenlerini anlamayı gerektirir. Ana bozulma desenlerine ve Performance Monitoring verilerini kullanarak bunların nasıl teşhis edileceğine bakalım. Yaklaşım: bir metrikte anormallik bulun → tipik nedenleri kontrol edin → optimizasyonu uygulayın → bir hafta sonra sonucu doğrulayın.

Yavaş soğuk başlatma (> 2 saniye): nedenler — Application.onCreate'da ağır SDK başlatma (analiz, çökme raporlama, harita SDK), büyük kaynakları yükleme (yazı tipleri, temalar), başlatmada ana iş parçacığında senkron işlemler. Çözümler: tembel SDK başlatma, gecikmeli kaynak yükleme, başlatma sırasında bir yer tutucu göstermek için SplashScreen API (Android 12+) kullanımı. Firebase Performance hangi uygulama sürümünün yavaşlamaya başladığını gösterecektir — hangi bağımlılıkların eklendiğini veya güncellendiğini kontrol edin.

Yavaş ekran oluşturma (> 500 ms): nedenler — karmaşık View hiyerarşisi (iç içe ConstraintLayout, birden çok Fragment), UI iş parçacığında veri yükleme (ağ veya disk), ağır çizim işlemleri (büyük görüntüler, özel View). Çözümler: düzen hiyerarşisini optimize edin (Android Studio'da Layout Inspector), verileri arka plan iş parçacığına aktarın, Glide veya Coil ile görüntüleri önbelleğe alın. En yavaş ekranı bulmak ve önce onu optimize etmek için Firebase'de Ekran Oluşturma filtresini kullanın.

Ağ İsteklerini Optimize Etme

Yavaş HTTP istekleri (> 3 saniye): nedenler — yavaş sunucu, büyük yükler, önbellekleme eksikliği, optimal olmayan protokol (HTTP/2 yerine HTTP/1.1), DNS çözümlemesi. Çözümler: sunucu tarafını kontrol edin (çalışma süresi, gecikme), yanıt boyutunu azaltın (sayfalama, GraphQL, JSON yerine protobuf), HTTP başlıkları (Cache-Control) aracılığıyla önbellekleme etkinleştirin, zaman aşımları ve yeniden deneme mantığı eklemek için OkHttp Interceptor kullanın.

Firebase Performance, isteğin zaman dağılımını gösterir: DNS çözümlemesi, TCP el sıkışması, TLS el sıkışması, istek gönderme, yanıt alma. Zamanın çoğu DNS'e harcanıyorsa — DNS ön yüklemesi (OkHttp DNS-over-HTTPS) kullanın. TLS'de ise — oturum devam ettirme ve şifre paketi ayarlama kullanın. Yanıt almadaysa — yanıt boyutunu ve kullanıcı ağ hızını kontrol edin. Firebase verileri, yalnızca "istek yavaş" demek yerine sorunu protokol düzeyinde belirlemeye olanak tanır.

İzlemeyi Devre Dışı Bırakmak İçin Remote Config Entegrasyonu

Üretim için, özel izlemeleri uzaktan devre dışı bırakmaya olanak tanıyan bir Remote Config bayrağı performance_tracing_enabled eklenmesi önerilir. İstemcideki Firebase Performance SDK çok fazla veri üretiyorsa veya performansı etkiliyorsa (zayıf cihazlarda), tüm kullanıcılar için izlemeleri devre dışı bırakabilir ve yalnızca minimum ek yükü olan otomatik metrikleri bırakabilirsiniz.

Örnek mantık: uygulama başlatıldığında, Remote Config parametresi performance_tracing_enabled kontrol edin. false ise — Firebase.performance.newTrace() çağrılarının tümü, veri toplamayan bir saplama nesnesi döndürür. Bu, bir izleme oluşturmadan önce bayrağı kontrol eden bir sarmalayıcı sınıf aracılığıyla uygulanır. Bu yaklaşım, tüm kitleyi etkilemeden belirli kullanıcılar (beta testçileri, geliştiriciler) için ayrıntılı izlemeyi etkinleştirmeye olanak tanır.