Firebase Performance: apa itu, metrik dan cara melacaknya

Apa itu Firebase Performance Monitoring

Firebase Performance Monitoring adalah SDK dan platform cloud untuk mengumpulkan, mengagregasi, dan memvisualisasikan metrik kinerja aplikasi mobile. SDK ditanamkan ke dalam aplikasi dan secara otomatis menginstrumentasi titik-titik kunci: siklus hidup Activity (Android) atau ViewController (iOS), permintaan jaringan melalui URLSession (iOS) atau OkHttp (Android), dan panggilan sistem. Data yang terkumpul dikirim ke server Firebase, di mana data tersebut diagregasi berdasarkan versi aplikasi, perangkat, negara, dan atribut lainnya.

Arsitektur Performance SDK dibangun berdasarkan prinsip overhead minimal: instrumentasi menambahkan tidak lebih dari 1–2% ke waktu eksekusi operasi yang diukur. Data dikumpulkan secara asinkron dan di-buffer di perangkat sebelum dikirim, yang menghilangkan dampak pada kinerja thread UI. Pengiriman data terjadi sesuai jadwal (secara default setiap 30 menit) atau ketika buffer mencapai 100 KB.

Perbedaan utama antara Firebase Performance dan profiler Android Studio (CPU Profiler) atau Xcode Instruments adalah pemantauan produksi. Firebase Performance mengumpulkan data dari perangkat pengguna nyata, bukan hanya dari perangkat pengembang. Ini memungkinkan mendeteksi masalah yang hanya terjadi pada model tertentu, versi OS, atau di wilayah tertentu — yaitu masalah yang tidak dapat direproduksi di lingkungan terkendali.

Bagaimana SDK mengumpulkan data tanpa mengubah kode

Instrumentasi otomatis adalah fitur utama Firebase Performance. Untuk Android, SDK secara otomatis mendaftarkan ActivityLifecycleCallbacks dan mengukur waktu antara onCreate dan onResume (waktu rendering layar). Untuk iOS — melakukan swizzle pada metode viewDidLoad dan viewDidAppear. Permintaan jaringan dicegat di tingkat OkHttpInterceptor (Android) atau NSURLProtocol (iOS). Pengembang tidak perlu menambahkan panggilan start/stop untuk metrik standar.

Mengaktifkan dan menonaktifkan Performance SDK dikelola melalui plugin Google Services (Android) atau Info.plist (iOS). Untuk debugging, logging verbose Performance SDK dapat diaktifkan, yang akan menunjukkan metrik apa yang dikumpulkan dan dikirim. Dalam produksi, disarankan untuk mempertahankan logging di tingkat warning agar tidak membanjiri log dengan informasi yang tidak perlu. Untuk proyek Flutter atau React Native, instrumentasi otomatis mungkin terbatas — detail lebih lanjut di bagian contoh kode.

Batas gratis dan tarif

Firebase Performance ditawarkan pada tarif gratis Spark tanpa batasan jumlah jejak atau volume data. Tarif berbayar Blaze juga tidak mengenakan biaya untuk Performance Monitoring — ini adalah salah satu dari sedikit layanan Firebase yang sepenuhnya gratis di kedua tarif. Hanya ada satu batasan: data disimpan selama 30 hari (di Spark) dan hingga 365 hari (di Blaze). Untuk analisis jangka panjang, ekspor data melalui BigQuery export.

Tidak ada biaya menjadikan Firebase Performance pilihan ideal untuk proyek apa pun — dari prototipe hingga aplikasi enterprise dengan jutaan pengguna. Satu-satunya pos biaya adalah lalu lintas keluar data Performance SDK, tetapi ini dapat diabaikan dibandingkan dengan operasi jaringan lain dari aplikasi (kurang dari 1 MB per bulan per perangkat). Di BigQuery export, biaya dikenakan untuk penyimpanan dan kueri, tetapi Performance SDK itu sendiri gratis.

Metrik otomatis: apa yang diukur tanpa kode

Firebase Performance secara otomatis mengumpulkan lima kategori metrik tanpa satu baris kode pun: waktu startup aplikasi (app start), permintaan lambat (slow HTTP requests), kecepatan rendering layar (screen rendering), penggunaan memori (memory usage, hanya Android), dan kecepatan bingkai (frame rate, hanya Android). Metrik ini tersedia di konsol Firebase segera setelah menghubungkan SDK dan sesi pengguna pertama.

App Start Time — waktu dari memulai proses hingga UI siap sepenuhnya untuk interaksi. Dibagi menjadi cold start (aplikasi dimulai dari awal) dan warm start (aplikasi dipulihkan dari latar belakang). Cold start mencakup memuat file DEX, inisialisasi bidang statis, panggilan Application.onCreate dan Activity.onCreate. Firebase secara otomatis mengklasifikasikan jenis startup dan menunjukkan distribusi waktu untuk setiap jenis.

Screen Rendering Time — waktu dari awal memuat layar (onCreate untuk Android, viewDidLoad untuk iOS) hingga layar siap untuk interaksi (onResume, viewDidAppear). Firebase mengagregasi data untuk setiap layar (berdasarkan nama kelas atau custom screen name), memungkinkan menentukan layar mana yang paling lambat dimuat. Untuk Android, dropped frames juga diukur — jumlah bingkai yang terlewat selama rendering layar (jank).

Permintaan jaringan (HTTP/HTTPS)

Performance SDK secara otomatis mencegat dan mengukur setiap permintaan HTTP/HTTPS yang dikirim dari aplikasi melalui URLSession, OkHttp, atau URLConnection. Untuk setiap permintaan, dicatat: URL (jalur tanpa parameter kueri untuk keamanan), metode HTTP, kode respons, ukuran respons dalam byte, durasi permintaan, dan kecepatan koneksi (WiFi, Cellular). Data diagregasi di dasbor „Network Requests” konsol Firebase.

Slow Requests — permintaan yang durasinya melebihi ambang batas yang ditentukan. Ambang batas default untuk „permintaan lambat” adalah 4000 ms. Metrik ini sangat penting untuk mengidentifikasi masalah dengan sisi server: jika setelah pembaruan backend jumlah permintaan lambat meningkat dari 1% menjadi 15%, ini adalah sinyal untuk analisis log server segera. Pengguna tidak akan menunggu respons lebih dari 5 detik — data Firebase menunjukkan bahwa 53% pengguna menutup aplikasi jika permintaan berlangsung lebih dari 3 detik.

Keterbatasan instrumentasi otomatis

Keterbatasan iOS: di iOS, Performance SDK tidak dapat mengukur dropped frames (ini adalah API privat). Untuk mengukur jank di iOS, gunakan MetricKit atau CADisplayLink. Juga di iOS, SDK tidak mencegat permintaan yang dilakukan melalui klien HTTP pihak ketiga yang tidak menggunakan URLSession (misalnya, SwiftNIO). Untuk kasus seperti itu, gunakan jejak kustom dengan atribut HTTP.

Keterbatasan Android: di Android, pengukuran memori otomatis hanya tersedia pada perangkat dengan Android 8.0+ (API 26+). Untuk versi lama, gunakan jejak kustom dengan mendapatkan data melalui Debug.getMemoryInfo(). SDK juga tidak mencegat koneksi WebSocket — untuk itu diperlukan jejak terpisah. Meskipun ada keterbatasan, metrik otomatis mencakup 80% kebutuhan pemantauan kinerja.

Jejak kustom dan atribut HTTP

Jejak kustom (custom traces) adalah interval waktu bernama yang dibuat pengembang secara manual untuk mengukur kinerja skenario tertentu: memuat feed berita, memproses gambar, menyinkronkan data, mengeksekusi kueri basis data yang kompleks. Jejak kustom melengkapi metrik otomatis dan memungkinkan mengukur bagian kode yang dianggap kritis oleh pengembang untuk kinerja.

Setiap jejak memiliki nama (maksimum 100 karakter) dan dapat berisi hingga 5 metrik (metrics) kustom — nilai numerik yang dicatat di dalam jejak. Misalnya, dalam jejak „image_processing” dapat diukur metrik „original_file_size” dan „processed_file_size”. Metrik ditampilkan di konsol Firebase sebagai distribusi (min, max, average, persentil), yang memungkinkan analisis tidak hanya durasi tetapi juga karakteristik operasi.

Atribut HTTP adalah jenis khusus jejak kustom untuk permintaan jaringan yang tidak dicegat secara otomatis oleh SDK (misalnya, melalui WebSocket atau pustaka pihak ketiga). Atribut HTTP mencakup URL, metode HTTP, kode respons, dan ukuran respons. Firebase menampilkannya di bagian „Network Requests” bersama dengan permintaan yang dikumpulkan secara otomatis, memberikan gambaran terpadu tentang interaksi jaringan.

Kapan menggunakan jejak kustom

Jejak kustom sangat diperlukan untuk mengukur: waktu memuat data dari basis data lokal (Room, CoreData), durasi perhitungan kompleks (enkripsi, kompresi), kinerja animasi dan transisi, waktu respons SDK pihak ketiga (peta, pembayaran, analitik). Untuk setiap skenario tersebut, buat jejak, bungkus kode yang diukur dalam start/stop, dan tambahkan atribut untuk segmentasi selanjutnya.

Jangan berlebihan menggunakan jejak kustom. Setiap jejak berarti konsumsi baterai dan lalu lintas tambahan. Disarankan tidak lebih dari 10–15 jejak aktif dalam versi produksi aplikasi. Untuk debugging, lebih banyak jejak dapat ditambahkan, tetapi sebelum rilis, nonaktifkan yang berlebihan melalui Remote Config (gunakan bendera performance_tracing_enabled). Ini memungkinkan pelacakan terperinci hanya untuk pengguna atau sesi tertentu.

Atribut jejak untuk segmentasi

Atribut kustom (custom attributes) adalah pasangan kunci-nilai yang dapat ditambahkan ke jejak untuk pemfilteran selanjutnya di konsol Firebase. Misalnya, ke jejak „feed_load” dapat ditambahkan atribut „feed_type” (main, explore, following) dan „cache_status” (cold, warm). Di konsol, data jejak dapat difilter berdasarkan atribut ini untuk menentukan jenis feed mana yang paling lambat dimuat.

Keterbatasan: setiap jejak dapat memiliki hingga 5 atribut kustom. Nilai atribut adalah string hingga 100 karakter. Atribut harus diatur sebelum jejak dimulai; perubahan atribut setelah dimulai akan diabaikan. Keterbatasan ini terkait dengan kinerja: mengatur atribut setelah mulai akan memerlukan sinkronisasi tambahan.

Ambang batas kinerja dan peringatan

Ambang batas (thresholds) adalah nilai batas metrik yang dapat dikonfigurasi, ketika dilampaui Firebase Performance menghasilkan peringatan. Ambang batas diatur di konsol Firebase (bagian Performance > Thresholds) untuk setiap metrik otomatis: app start time (cold/warm), screen rendering time, slow HTTP requests, HTTP response time. Ambang batas global dapat diatur untuk semua versi aplikasi atau spesifik untuk versi tertentu.

Peringatan (alerts) adalah pemberitahuan otomatis yang dikirim Firebase ketika ambang batas terlampaui. Peringatan dapat dikonfigurasi untuk email, Slack webhook, PagerDuty, atau Cloud Functions (untuk pemrosesan kustom). Setiap peringatan berisi: nama metrik, nilai saat ini, nilai ambang, versi aplikasi, segmen (perangkat, negara). Peringatan memungkinkan bereaksi terhadap degradasi kinerja sebelum menjadi terlihat oleh pengguna.

Ambang batas yang direkomendasikan menurut standar industri (Google I/O 2025): cold start — kurang dari 2 detik, warm start — kurang dari 1 detik, rendering layar — kurang dari 500 ms, durasi permintaan HTTP — kurang dari 3000 ms (persentil ke-95), proporsi permintaan lambat — kurang dari 5%. Untuk aplikasi dengan persaingan tinggi (Social, E-commerce), ambang batas target bisa lebih ketat: cold start < 1,5 detik, HTTP < 1000 ms.

Mengatur ambang batas di konsol Firebase

Di konsol Firebase buka bagian Performance, buka tab Thresholds. Untuk setiap metrik, atur nilai ambang yang diinginkan dan persentase pengguna yang harus terpengaruh oleh pelampauan. Misalnya: „kami menganggap cold start lambat jika melebihi 2 detik untuk lebih dari 10% pengguna”. Firebase akan menampilkan nilai metrik saat ini dan riwayat pelampauan untuk membantu memilih ambang batas yang realistis.

Penting: ambang batas tidak memengaruhi pengumpulan data, mereka hanya mengelola pembuatan pemberitahuan. Jika ambang batas terlalu rendah (misalnya, cold start 1 detik, padahal 50% perangkat mulai dalam 3 detik), peringatan akan terus datang dan menjadi „kebisingan” yang tidak lagi diperhatikan pengembang. Tetapkan ambang batas berdasarkan indikator saat ini, kemudian secara bertahap perketat saat Anda mengoptimalkan aplikasi.

Dasbor Performance di konsol Firebase

Dasbor Performance menampilkan metrik kunci sebagai deret waktu dengan perincian berdasarkan versi aplikasi, perangkat, negara, jenis koneksi, dan versi OS. Untuk setiap metrik tersedia: rata-rata, median, persentil ke-95, persentil ke-99. Persentil ke-95 adalah metrik paling informatif untuk mengevaluasi kinerja karena menunjukkan bagaimana aplikasi bekerja pada perangkat lemah, mengabaikan nilai pencilan.

Dasbor mendukung perbandingan versi: pilih dua versi aplikasi (saat ini dan sebelumnya) untuk perbandingan visual metrik. Jika setelah pembaruan persentil ke-95 waktu startup meningkat dari 2,1 menjadi 3,4 detik — regresi jelas dan perlu menemukan commit yang menyebabkan perlambatan. Firebase Performance terintegrasi dengan GitHub, GitLab, dan Bitbucket, memungkinkan menghubungkan perubahan metrik dengan commit tertentu.

Contoh kode untuk Performance Monitoring

Mari kita lihat contoh integrasi Firebase Performance Monitoring dalam aplikasi Android dengan Kotlin. Kode menunjukkan pembuatan jejak kustom untuk mengukur pemuatan feed berita, menambahkan atribut HTTP untuk permintaan yang tidak dicegat secara otomatis, dan menggunakan Trace untuk mengukur waktu pemrosesan gambar. Semua contoh mempertimbangkan kemungkinan menonaktifkan pelacakan melalui Remote Config.

Sebelum digunakan, tambahkan dependensi: implementation("com.google.firebase:firebase-perf") melalui Firebase BOM. Untuk instrumentasi otomatis, tidak diperlukan konfigurasi tambahan — SDK mencegat operasi standar secara otomatis setelah menghubungkan dependensi.

Jejak kustom untuk memuat feed

Contoh pertama — mengukur waktu muat feed berita dari server. Jejak membungkus operasi asinkron fetchFeed, yang mengambil data dari jaringan dan mem-parsing JSON. Ke jejak ditambahkan atribut kustom: sumber data (cache atau network) dan jumlah posting yang diterima. Ini memungkinkan segmentasi data dan memahami kondisi di mana feed paling lambat dimuat.

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

Fungsi loadFeedWithTrace menerima parameter source („cache” atau „network”), yang digunakan sebagai atribut jejak. Setelah operasi asinkron selesai, jejak dihentikan di blok finally, menjamin penghentian bahkan saat terjadi pengecualian. Metrik items_count memungkinkan menganalisis bagaimana jumlah posting memengaruhi waktu muat. Di konsol Firebase, jejak dapat difilter berdasarkan atribut source dan terlihat bahwa pemuatan dari jaringan 3 kali lebih lambat daripada dari cache.

Atribut HTTP untuk permintaan tidak standar

Contoh kedua — atribut HTTP untuk permintaan yang dilakukan melalui WebSocket (tidak dicegat secara otomatis). Kelas HttpMetric digunakan, yang memungkinkan pendaftaran manual permintaan URL, metodenya, kode respons, dan ukuran. Firebase akan menampilkan permintaan ini di bagian Network Requests bersama dengan yang dicegat secara otomatis.

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

Dalam contoh, sendWithHttpMetric menggunakan newHttpMetric untuk mendaftarkan panggilan HTTP tidak standar. SDK tidak mencegatnya secara otomatis, sehingga pengembang secara manual mengatur URL, metode, kode respons, dan ukuran. Penting untuk mengatur URL tanpa parameter kueri (untuk keamanan dan agregasi) — yaitu /data, bukan /data?token=abc. Firebase secara otomatis mengelompokkan pola URL yang serupa.

Mengukur waktu pemrosesan gambar

Contoh ketiga menunjukkan pengukuran waktu pemrosesan gambar (kompresi, perubahan ukuran) menggunakan jejak kustom. Dalam kasus ini, jejak membungkus operasi sinkron, tetapi untuk produksi gunakan coroutine atau RxJava agar tidak memblokir thread UI.

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
}

Fungsi compressImage mengukur waktu kompresi gambar ke JPEG dengan kualitas 80%. Atribut format memungkinkan perbandingan waktu kompresi JPEG vs WebP di masa mendatang. Metrik output_size_kb menunjukkan seberapa efisien kompresi. Di konsol Firebase, distribusi dapat dilihat: pada perangkat lemah (Android murah) kompresi memakan waktu 4 kali lebih lama daripada di flagship, yang dapat menjadi penyebab keterlambatan saat mengirim gambar ke server.

Cara meningkatkan kinerja berdasarkan data

Firebase Performance menyediakan data, tetapi tidak memberikan solusi siap pakai. Analisis metrik memerlukan pemahaman tentang penyebab umum degradasi kinerja untuk setiap metrik. Mari kita lihat pola utama penurunan dan metode diagnosisnya berdasarkan data Performance Monitoring. Pendekatan: temukan anomali dalam metrik → periksa penyebab umum → terapkan optimasi → periksa hasilnya dalam seminggu.

Cold start lambat (> 2 detik): penyebab — inisialisasi SDK yang berat di Application.onCreate (analitik, crash reporting, map SDK), memuat sumber daya besar (font, tema), operasi sinkron di thread utama saat startup. Solusi: inisialisasi lambat SDK, pemuatan sumber daya yang ditunda, penggunaan SplashScreen API (Android 12+) untuk menampilkan placeholder selama inisialisasi. Firebase Performance akan menunjukkan versi aplikasi mana yang mulai lebih lambat — periksa dependensi apa yang ditambahkan atau diperbarui.

Rendering layar lambat (> 500 ms): penyebab — hierarki View yang kompleks (ConstraintLayout bersarang, banyak Fragment), memuat data di thread UI (jaringan atau disk), operasi draw yang berat (gambar besar, View kustom). Solusi: optimasi hierarki tata letak (Layout Inspector di Android Studio), memindahkan data ke thread latar belakang, caching gambar melalui Glide atau Coil. Gunakan filter Screen Rendering di Firebase untuk menemukan layar paling lambat dan mengoptimalkannya terlebih dahulu.

Optimasi permintaan jaringan

Permintaan HTTP lambat (> 3 detik): penyebab — server lambat, payload besar, tidak ada caching, protokol tidak optimal (HTTP/1.1 alih-alih HTTP/2), resolusi DNS. Solusi: periksa sisi server (uptime, latency), kurangi ukuran respons (paginasi, GraphQL, protobuf alih-alih JSON), aktifkan caching melalui header HTTP (Cache-Control), gunakan OkHttp Interceptor untuk menambahkan batas waktu dan logika percobaan ulang.

Firebase Performance menunjukkan distribusi waktu permintaan: resolusi DNS, jabat tangan TCP, jabat tangan TLS, pengiriman permintaan, penerimaan respons. Jika sebagian besar waktu dihabiskan untuk DNS — gunakan pramuat DNS (OkHttp DNS-over-HTTPS). Jika untuk TLS — gunakan session resumption dan penyesuaian cipher suites. Jika untuk penerimaan respons — periksa ukuran respons dan kecepatan jaringan pengguna. Data Firebase memungkinkan melokalisasi masalah di tingkat protokol, bukan hanya mengatakan „permintaan lambat”.

Integrasi Remote Config untuk menonaktifkan pelacakan

Untuk produksi disarankan menambahkan bendera Remote Config performance_tracing_enabled, yang memungkinkan menonaktifkan jejak kustom dari jarak jauh. Jika Firebase Performance SDK di sisi klien menghasilkan terlalu banyak data atau memengaruhi kinerja (pada perangkat lemah), jejak dapat dinonaktifkan untuk semua pengguna, hanya menyisakan metrik otomatis yang memiliki overhead minimal.

Contoh logika: saat aplikasi dimulai, periksa parameter Remote Config performance_tracing_enabled. Jika false — semua panggilan Firebase.performance.newTrace() mengembalikan objek stub yang tidak mengumpulkan data. Ini diimplementasikan melalui kelas wrapper yang memeriksa bendera sebelum membuat jejak. Pendekatan semacam itu memungkinkan pelacakan terperinci untuk pengguna tertentu (penguji beta, pengembang) tanpa memengaruhi seluruh audiens.