Firebase Performance: що це, метрики та як відстежувати

Що таке Firebase Performance Monitoring

Firebase Performance Monitoring — це SDK і хмарна платформа для збору, агрегації та візуалізації метрик продуктивності мобільних додатків. SDK вбудовується в додаток та автоматично інструментує ключові точки: життєвий цикл Activity (Android) або ViewController (iOS), мережеві запити через URLSession (iOS) або OkHttp (Android) і системні виклики. Зібрані дані відправляються на сервер Firebase, де агрегуються за версіями додатка, пристроями, країнами та іншими атрибутами.

Архітектура Performance SDK побудована на принципі мінімального навантаження: інструментація додає не більше 1–2% до часу виконання вимірюваних операцій. Дані збираються асинхронно та буферизуються на пристрої перед відправкою, що виключає вплив на продуктивність UI-потоку. Відправка даних відбувається за розкладом (за замовчуванням кожні 30 хвилин) або після досягнення буфера 100 КБ.

Ключова відмінність Firebase Performance від профайлерів Android Studio (CPU Profiler) або Xcode Instruments — моніторинг у продакшені. Firebase Performance збирає дані з реальних пристроїв користувачів, а не тільки з пристроїв розробника. Це дозволяє виявляти проблеми, які відтворюються лише на певних моделях, версіях ОС або в конкретних регіонах — тобто проблеми, які неможливо відтворити в контрольованому середовищі.

Як SDK збирає дані без зміни коду

Автоматична інструментація — головна особливість Firebase Performance. Для Android SDK автоматично реєструє ActivityLifecycleCallbacks та вимірює час між onCreate та onResume (час рендерингу екрана). Для iOS — swizzles методи viewDidLoad та viewDidAppear. Мережеві запити перехоплюються на рівні OkHttpInterceptor (Android) або NSURLProtocol (iOS). Розробнику не потрібно додавати виклики start/stop для стандартних метрик.

Увімкнення та вимкнення Performance SDK керується через Google Services плагін (Android) або Info.plist (iOS). Для налагодження можна ввімкнути детальне логування Performance SDK, яке покаже, які метрики збираються та відправляються. У продакшені рекомендується залишити логування на рівні попереджень, щоб не засмічувати логи зайвою інформацією. Для проєктів на Flutter або React Native автоматична інструментація може бути обмежена — докладніше в розділі прикладів коду.

Безкоштовні ліміти та тарифікація

Firebase Performance пропонується на безкоштовному тарифі Spark без обмежень за кількістю трейсів або обсягом даних. Платний тариф Blaze також не стягує плату за Performance Monitoring — це один із небагатьох сервісів Firebase, повністю безкоштовних на обох тарифах. Обмеження лише одне: дані зберігаються 30 днів (на Spark) і до 365 днів (на Blaze). Для довгострокового аналізу вивантажуйте дані через BigQuery export.

Відсутність плати робить Firebase Performance ідеальним вибором для будь-якого проєкту — від прототипу до корпоративного додатка з мільйонами користувачів. Єдина стаття витрат — вихідний трафік даних Performance SDK, але він мізерний порівняно з іншими мережевими операціями додатка (менше 1 МБ на місяць на пристрій). BigQuery export стягує плату за зберігання та запити, але сам Performance SDK — безкоштовний.

Автоматичні метрики: що вимірюється без коду

Firebase Performance автоматично збирає п'ять категорій метрик без жодного рядка коду: час запуску додатка, повільні запити, швидкість рендерингу екранів, споживання пам'яті (тільки Android) і частота кадрів (тільки Android). Ці метрики доступні в консолі Firebase одразу після підключення SDK та першого сеансу користувача.

Час запуску додатка — час від запуску процесу до повної готовності UI до взаємодії. Розділяється на холодний старт (додаток запускається з нуля) і теплий старт (додаток відновлюється з фонового стану). Холодний старт включає завантаження DEX-файлів, ініціалізацію статичних полів, виклик Application.onCreate та Activity.onCreate. Firebase автоматично класифікує тип старту та показує розподіл часу для кожного типу.

Час рендерингу екрана — час від початку завантаження екрана (onCreate для Android, viewDidLoad для iOS) до моменту, коли екран готовий до взаємодії (onResume, viewDidAppear). Firebase агрегує дані по кожному екрану (за ім'ям класу або кастомним ім'ям екрана), дозволяючи визначити, який екран завантажується найдовше. Для Android додатково вимірюються пропущені кадри — кількість кадрів, пропущених під час рендерингу екрана (jank).

Мережеві запити (HTTP/HTTPS)

Performance SDK автоматично перехоплює та вимірює кожен HTTP/HTTPS запит, відправлений із додатка через URLSession, OkHttp або URLConnection. Для кожного запиту фіксуються: URL (шлях без query-параметрів для безпеки), HTTP-метод, код відповіді, розмір відповіді в байтах, тривалість запиту та швидкість з'єднання (WiFi, мобільний). Дані агрегуються в дашборді "Мережеві запити" консолі Firebase.

Повільні запити — запити, тривалість яких перевищує заданий поріг. За замовчуванням поріг "повільного запиту" — 4000 мс. Ця метрика критично важлива для виявлення проблем із серверною частиною: якщо після оновлення бекенда кількість повільних запитів зросла з 1% до 15%, це сигнал до негайного аналізу серверних логів. Користувачі не чекатимуть відповіді більше 5 секунд — дані Firebase показують, що 53% користувачів закривають додаток, якщо запит виконується довше 3 секунд.

Обмеження автоматичної інструментації

Обмеження iOS: на iOS Performance SDK не може виміряти пропущені кадри (це приватний API). Для вимірювання jank на iOS використовуйте MetricKit або CADisplayLink. Також на iOS SDK не перехоплює запити, виконані через сторонні HTTP-клієнти, які не використовують URLSession (наприклад, SwiftNIO). Для таких випадків використовуйте кастомні трейси з HTTP-атрибутами.

Обмеження Android: на Android автоматичне вимірювання пам'яті доступне лише на пристроях з Android 8.0+ (API 26+). Для старих версій використовуйте кастомні трейси з отриманням даних через Debug.getMemoryInfo(). Також SDK не перехоплює WebSocket-з'єднання — для них потрібні окремі трейси. Незважаючи на обмеження, автоматичні метрики покривають 80% потреб у моніторингу продуктивності.

Кастомні трейси та HTTP-атрибути

Кастомні трейси (custom traces) — це іменовані інтервали часу, які розробник створює вручну для вимірювання продуктивності конкретних сценаріїв: завантаження стрічки новин, обробка зображення, синхронізація даних, виконання складного запиту до бази даних. Кастомні трейси доповнюють автоматичні метрики та дозволяють вимірювати саме ті ділянки коду, які розробник вважає критичними для продуктивності.

Кожен трейс має ім'я (максимум 100 символів) і може містити до 5 користувацьких метрик — числових значень, які записуються всередині трейса. Наприклад, у трейсі "image_processing" можна виміряти метрики "original_file_size" та "processed_file_size". Метрики відображаються в консолі Firebase як розподіли (min, max, середнє, перцентилі), що дозволяє аналізувати не тільки тривалість, а й характеристики операції.

HTTP-атрибути — спеціальний тип кастомних трейсів для мережевих запитів, які не були автоматично перехоплені SDK (наприклад, через WebSocket або сторонні бібліотеки). HTTP-атрибути включають URL, HTTP-метод, код відповіді та розмір відповіді. Firebase відображає їх у розділі "Мережеві запити" разом із автоматично зібраними запитами, забезпечуючи єдину картину мережевої взаємодії.

Коли використовувати кастомні трейси

Кастомні трейси незамінні для вимірювання: часу завантаження даних із локальної бази даних (Room, CoreData), тривалості складних обчислень (шифрування, компресія), продуктивності анімацій та переходів, часу відповіді сторонніх SDK (карти, платежі, аналітика). Для кожного такого сценарію створіть трейс, оберніть вимірюваний код у start/stop та додайте атрибути для подальшої сегментації.

Не зловживайте кастомними трейсами. Кожен трейс — це додаткове споживання батареї та трафіку. Рекомендується не більше 10–15 активних трейсів у продакшен-версії додатка. Для налагодження можна додати більше трейсів, але перед релізом вимкніть надлишкові через Remote Config (використовуйте прапорець performance_tracing_enabled). Це дозволяє вмикати детальне трасування лише для вибраних користувачів або сеансів.

Атрибути трейсів для сегментації

Користувацькі атрибути — це пари ключ-значення, які можна додати до трейса для подальшої фільтрації в консолі Firebase. Наприклад, до трейса "feed_load" можна додати атрибути "feed_type" (main, explore, following) та "cache_status" (cold, warm). У консолі дані трейса можна відфільтрувати за цими атрибутами, щоб визначити, який тип стрічки завантажується найповільніше.

Обмеження: кожен трейс може мати до 5 користувацьких атрибутів. Значення атрибута — рядок до 100 символів. Атрибути повинні бути задані до старту трейса; зміна атрибута після старту ігнорується. Це обмеження пов'язане з продуктивністю: фіксація атрибутів після старту потребувала б додаткової синхронізації.

Пороги продуктивності та сповіщення

Пороги (thresholds) — це налаштовувані граничні значення метрик, при перевищенні яких Firebase Performance генерує попередження. Пороги задаються в консолі Firebase (розділ Performance > Thresholds) для кожної автоматичної метрики: час запуску додатка (холодний/тепли), час рендерингу екрана, повільні HTTP-запити, час відповіді HTTP. Можна задати глобальні пороги для всіх версій додатка або специфічні для конкретних версій.

Сповіщення (alerts) — автоматичні повідомлення, які Firebase відправляє при перевищенні порога. Сповіщення можна налаштувати на email, Slack webhook, PagerDuty або Cloud Functions (для кастомної обробки). Кожне сповіщення містить: назву метрики, поточне значення, порогове значення, версію додатка, сегмент (пристрій, країна). Сповіщення дозволяють реагувати на деградацію продуктивності до того, як вона стане помітною користувачам.

Рекомендовані пороги за галузевим стандартом (Google I/O 2025): холодний старт — менше 2 секунд, теплий старт — менше 1 секунди, рендеринг екрана — менше 500 мс, тривалість HTTP-запиту — менше 3000 мс (95-й перцентиль), частка повільних запитів — менше 5%. Для додатків із високою конкуренцією (соціальні, електронна комерція) цільові пороги можуть бути жорсткішими: холодний старт < 1,5 секунди, HTTP < 1000 мс.

Налаштування порогів у консолі Firebase

У консолі Firebase перейдіть у розділ Performance, відкрийте вкладку Thresholds. Для кожної метрики задайте бажане порогове значення та відсоток користувачів, яких має торкнутися перевищення. Наприклад: "вважаємо холодний старт повільним, якщо він перевищує 2 секунди для більш ніж 10% користувачів". Firebase покаже поточні значення метрик та історію перевищень для допомоги у виборі реалістичних порогів.

Важливо: пороги не впливають на збір даних, вони тільки керують генерацією повідомлень. Якщо поріг занадто низький (наприклад, холодний старт 1 секунда, хоча 50% пристроїв запускаються за 3 секунди), сповіщення приходитимуть постійно і стануть "шумом", який розробники перестануть помічати. Виставляйте пороги на основі поточних показників, потім поступово посилюйте їх у міру оптимізації додатка.

Performance Dashboard у консолі Firebase

Дашборд Performance відображає ключові метрики у вигляді часових рядів із розбивкою за версією додатка, пристроєм, країною, типом з'єднання та версією ОС. Для кожної метрики доступні: середнє значення, медіана, 95-й перцентиль, 99-й перцентиль. 95-й перцентиль — найбільш інформативна метрика для оцінки продуктивності, оскільки вона показує, як додаток працює "на слабких пристроях", ігноруючи викиди.

Дашборд підтримує порівняння версій: виберіть дві версії додатка (поточну та попередню) для візуального порівняння метрик. Якщо після оновлення 95-й перцентиль часу запуску зріс із 2,1 до 3,4 секунди — регресія очевидна, і потрібно знайти коміт, який спричинив уповільнення. Firebase Performance інтегрується з GitHub, GitLab та Bitbucket, що дозволяє пов'язувати зміни метрик із конкретними комітами.

Приклади коду для Performance Monitoring

Розглянемо приклади інтеграції Firebase Performance Monitoring в Android-додаток на Kotlin. Код демонструє створення кастомного трейса для вимірювання завантаження стрічки новин, додавання HTTP-атрибута для неавтоматично перехопленого запиту та використання Trace для вимірювання часу обробки зображення. Всі приклади враховують можливість вимкнення трасування через Remote Config.

Перед використанням додайте залежність: implementation("com.google.firebase:firebase-perf") через Firebase BOM. Для автоматичної інструментації додаткового налаштування не потрібно — SDK перехоплює стандартні операції автоматично після підключення залежності.

Кастомний трейс для завантаження стрічки

Перший приклад — вимірювання часу завантаження стрічки новин із сервера. Трейс обгортає асинхронну операцію fetchFeed, яка отримує дані з мережі та парсить JSON. У трейс додані користувацькі атрибути: джерело даних (cache або network) та кількість отриманих постів. Це дозволяє сегментувати дані та зрозуміти, за яких умов стрічка завантажується найдовше.

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 приймає параметр source ("cache" або "network"), який використовується як атрибут трейса. Після завершення асинхронної операції трейс зупиняється в блоці finally, гарантуючи зупинку навіть при винятку. Метрика items_count дозволяє аналізувати, як кількість постів впливає на час завантаження. У консолі Firebase можна відфільтрувати трейси за атрибутом source і побачити, що завантаження з мережі в 3 рази повільніше за кеш.

HTTP-атрибут для нестандартного запиту

Другий приклад — HTTP-атрибут для запиту, виконаного через WebSocket (не перехоплюється автоматично). Використовується клас HttpMetric, який дозволяє вручну зареєструвати URL-запит, його метод, код відповіді та розмір. Firebase відобразить цей запит у розділі Мережеві запити разом із автоматично перехопленими.

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

У прикладі sendWithHttpMetric використовує newHttpMetric для реєстрації нестандартного HTTP-виклику. SDK не перехоплює його автоматично, тому розробник вручну задає URL, метод, код відповіді та розміри. Важно задавати URL без query-параметрів (для безпеки та агрегації) — тобто /data, а не /data?token=abc. Firebase автоматично групує однакові URL-шаблони.

Вимірювання часу обробки зображення

Третій приклад демонструє вимірювання часу обробки зображення (стиснення, зміна розміру) за допомогою кастомного трейса. У цьому випадку трейс обгортає синхронну операцію, але для продакшену використовуйте корутини або RxJava, щоб не блокувати 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
}

Функція compressImage вимірює час стиснення зображення в JPEG з якістю 80%. Атрибут format дозволяє в майбутньому порівнювати час стиснення JPEG проти WebP. Метрика output_size_kb показує, наскільки ефективним є стиснення. У консолі Firebase можна побачити розподіл: на слабких пристроях (бюджетні Android) стиснення займає в 4 рази більше часу, ніж на флагманах, що може бути причиною затримок при відправці зображень на сервер.

Як покращувати продуктивність на основі даних

Firebase Performance надає дані, але не дає готових рішень. Аналіз метрик потребує розуміння типових причин деградації продуктивності для кожної метрики. Розглянемо основні патерни погіршення та способи їх діагностики за даними Performance Monitoring. Підхід: знайшли аномалію в метриці → перевірили типові причини → застосували оптимізацію → перевірили результат через тиждень.

Повільний холодний старт (> 2 секунд): причини — важка ініціалізація SDK в Application.onCreate (аналітика, crash reporting, map SDK), завантаження великих ресурсів (шрифти, теми), синхронні операції в головному потоці при старті. Рішення: лінива ініціалізація SDK, відкладене завантаження ресурсів, використання SplashScreen API (Android 12+) для показу placeholder під час ініціалізації. Firebase Performance покаже, яка версія додатка стала стартувати повільніше — перевірте, які залежності були додані або оновлені.

Повільний рендеринг екрана (> 500 мс): причини — складна ієрархія View (вкладені ConstraintLayout, множинні Fragment), завантаження даних у UI-потоці (мережа або диск), важкі draw-операції (великі зображення, кастомні View). Рішення: оптимізація layout-ієрархії (Layout Inspector в Android Studio), вивантаження даних у фоновий потік, кешування зображень через Glide або Coil. Використовуйте фільтр Screen Rendering у Firebase, щоб знайти найповільніший екран та оптимізувати його в першу чергу.

Оптимізація мережевих запитів

Повільні HTTP-запити (> 3 секунд): причини — повільний сервер, великі payload-и, відсутність кешування, неоптимальний протокол (HTTP/1.1 замість HTTP/2), DNS-резолвінг. Рішення: перевірте серверну сторону (аптайм, latency), зменшіть розмір відповіді (пагінація, GraphQL, protobuf замість JSON), увімкніть кешування через HTTP-заголовки (Cache-Control), використовуйте OkHttp Interceptor для додавання тайм-аутів та retry-логіки.

Firebase Performance показує розподіл часу запиту: DNS resolution, TCP handshake, TLS handshake, request send, response receive. Якщо більша частина часу припадає на DNS — використовуйте попереднє завантаження DNS (OkHttp DNS-over-HTTPS). Якщо на TLS — використовуйте session resumption та тюнінг cipher suites. Якщо на response receive — перевірте розмір відповіді та швидкість мережі користувача. Дані Firebase дозволяють локалізувати проблему на рівні протоколу, а не просто сказати "запит повільний".

Інтеграція Remote Config для вимкнення трасування

Для продакшену рекомендується додати Remote Config прапорець performance_tracing_enabled, який дозволяє віддалено вимикати кастомні трейси. Якщо Firebase Performance SDK на клієнті генерує занадто багато даних або впливає на продуктивність (на слабких пристроях), можна вимкнути трейси для всіх користувачів, залишивши лише автоматичні метрики, які мають мінімальне навантаження.

Приклад логіки: при старті додатка перевіряємо Remote Config параметр performance_tracing_enabled. Якщо false — всі виклики Firebase.performance.newTrace() повертають stub-об'єкт, який не збирає дані. Це реалізується через wrapper-клас, який перевіряє прапорець перед створенням трейса. Такий підхід дозволяє вмикати детальне трасування для конкретних користувачів (бета-тестерів, розробників) без впливу на всю аудиторію.