Time-to-Interactive у мобільній розробці: що це таке, метрика та вимірювання

Що таке Time-to-Interactive

Time-to-Interactive — це метрика продуктивності, яка фіксує момент, коли сторінка або додаток готовий до повноцінної взаємодії з користувачем. У контексті вебу TTI визначається як час від початку навігації до моменту, коли виконуються три умови: сторінка відобразила корисний вміст (First Contentful Paint), головний потік був вільний протягом щонайменше 5 секунд і всі слухачі подій зареєстровані. У мобільних додатках TTI — це час від моменту запуску Activity до повної ініціалізації UI, коли всі стани завантажено, анімації налаштовано і користувач може натиснути на будь-яку кнопку без затримки.

Ця метрика особливо важлива для додатків, де перша взаємодія критична — екрани логіну, пошуку, оформлення замовлення. Якщо TTI перевищує 5 секунд, користувач сприймає додаток як «завислий» і може закрити його. За даними Google (Web Vitals Report, 2025), сторінки з TTI менше 3.8 секунд показують на 24% більше конверсій, ніж сторінки з TTI більше 7 секунд. Різниця відчувається навіть у 500 мс — дослідження Amazon показують втрату 1% виручки за кожні 100 мс затримки.

Як розраховується TTI

Алгоритм розрахунку TTI визначено в специфікації W3C та реалізовано в інструменті Lighthouse. Розрахунок починається з First Contentful Paint (FCP) — моменту, коли браузер відобразив перший піксель вмісту. Потім алгоритм шукає «вікно тиші» — проміжок часу тривалістю 5 секунд, протягом якого в головному потоці не було задач тривалістю більше 50 мс. TTI фіксується на останній задачі перед цим вікном. Якщо вікно тиші не знайдено до 15 секунд, TTI вважається рівним часу останньої довгої задачі. Цей алгоритм гарантує, що TTI відображає реальну готовність до взаємодії, а не просто момент відображення.

У мобільних додатках (Android/iOS) точного аналога специфікації W3C немає, але концепція та ж. TTI можна виміряти, фіксуючи часову мітку в onResume (початок запуску) та в колбеку першого кадру, коли всі асинхронні операції завершено. Бібліотека Firebase Performance дозволяє задати спеціальний trace з початком і кінцем користувацької інтерактивної сесії. Наприклад, startTrace(“TTI”) в Application.onCreate та stopTrace() після завершення ініціалізації всіх SDK та відображення першого кадру.

Приклад спеціального trace для TTI

Код на Kotlin демонструє вимірювання TTI через Firebase Performance. Trace починається в Application.onCreate та зупиняється після першого reportFullyDrawn.

class App : Application() {

    private var ttiTrace: Trace? = null

    override fun onCreate() {
        super.onCreate()
        ttiTrace = Firebase.performance
            .newTrace("tti")
        ttiTrace?.start()
    }

    fun stopTtiTrace() {
        ttiTrace?.stop()
        ttiTrace = null
    }
}

TTI, FCP, LCP та FID: відмінності

В екосистемі Core Web Vitals існує кілька метрик, і TTI часто плутають із First Contentful Paint (FCP) та Largest Contentful Paint (LCP). FCP — час відображення першого пікселя вмісту, що не гарантує інтерактивність. LCP — час відображення найбільшого елемента вмісту (зображення, текстового блоку). TTI ж вимірює не відображення, а готовність до взаємодії. Різниця критична: FCP може бути 1.2 секунди, але якщо головний потік заблоковано завантаженням JS-бандла, TTI може досягати 8 секунд.

First Input Delay (FID) вимірює затримку між першою дією користувача та моментом, коли браузер почав обробку події. FID — це «якість інтерактивності», а TTI — «час до інтерактивності». Якщо TTI показує, через скільки секунд інтерфейс став чутливим, то FID — наскільки чутливим він був. Хороший TTI без хорошого FID неможливий, тому що якщо головний потік заблоковано, TTI буде високим, а FID — будь-яка взаємодія буде відкладена. У мобільних додатках аналогом FID служить Touch Latency — затримка між дотиком до екрана та реакцією UI.

TTI в мобільних додатках

У нативних мобільних додатках концепція TTI не стандартизована так, як у вебі, але її важливість не менша. В Android TTI — це час від кліку на іконку додатка до моменту, коли UI повністю інтерактивний: RecyclerView прокручується, кнопки реагують на натискання, анімації працюють без заїкань. Для вимірювання TTI в Android використовується комбінація reportFullyDrawn (API 29+) та FrameMetricsAggregator. reportFullyDrawn — це виклик, який додаток робить у момент, коли розробник вважає UI готовим. Система фіксує цей момент і включає його у звіт Android Vitals.

В iOS аналогом TTI служить метрика Time to First Frame та Time to Responsive. MetricKit збирає дані про час запуску з розбивкою на фази — завантаження виконуваного файлу, ініціалізація фреймворків, відображення першого кадру. Apple рекомендує, щоб Time to First Frame не перевищував 400 мс, а повна інтерактивність досягалася в межах 2 секунд. Якщо додаток показує екран-заглушку, а потім підвантажує вміст, TTI вважається не за першим кадром, а за моментом, коли реальний вміст готовий до взаємодії.

Вимірювання TTI в Android через FrameMetrics

Код на Kotlin відстежує перший інтерактивний кадр за допомогою FrameMetricsAggregator. Колбек спрацьовує після завершення першого кадру, ініційованого користувачем.

class TtiTracker(private val activity: Activity) {

    private val metrics = FrameMetricsAggregator()
    private var startTime = 0L

    fun onStart() {
        startTime = System.nanoTime()
        metrics.add(activity.window)
    }

    fun onFirstFrame() {
        val ttiMs = (System.nanoTime() - startTime) / 1_000_000
        Log.d("TTI", "Time to Interactive: $ttiMs ms")
        metrics.reset()
    }
}

Методи оптимізації TTI

Оптимізація TTI включає три напрямки: скорочення обсягу роботи в головному потоці, відкладене завантаження некритичних компонентів і прогресивний рендеринг. Перший напрямок — мінімізація синхронних операцій: заміна SharedPreferences на DataStore, перенесення ініціалізації SDK у фоновий потік, ліниве завантаження модулів Dagger/Hilt. Другий — відкладене завантаження: екрани, які не видно при старті (bottom sheets, діалоги, вкладки), мають ініціалізуватися після першого кадру. Третій — прогресивний рендеринг: спочатку показується skeleton-екран, потім вміст підвантажується частинами.

В Android ефективний метод — використання бібліотеки App Startup з ранжуванням ініціалізаторів. Наприклад, ініціалізатор Firebase Analytics можна зробити необов’язковим і відкласти його виконання на 2 секунди після старту. В iOS аналог — Initialization Dependencies з прапорцем lazy. Для вебу ключові методи — code splitting (розділення бандла), tree shaking (видалення мертвого коду), preload/preconnect для критичних ресурсів і defer для неблокуючого JS. Google Lighthouse дає конкретні рекомендації: «Eliminate render-blocking resources» та «Defer offscreen images» безпосередньо впливають на TTI.

Code Splitting в React Native

Приклад розділення бандла в React Native за допомогою React.lazy та Suspense. Компонент HeavyScreen завантажується тільки коли користувач переходить на цей екран, знижуючи TTI початкового екрана.

import React, { lazy, Suspense } from 'react';

const HeavyScreen = lazy(() =>
    import('./screens/HeavyScreen')
);

const App = () => (
    <Suspense fallback={<Loading />}>
        <HeavyScreen />
    </Suspense>
);

Інструменти для вимірювання TTI

Для вимірювання TTI існує кілька інструментів, які різняться за платформою та глибиною аналізу. У вебі основний інструмент — Lighthouse у Chrome DevTools. Lighthouse запускає аудит і виводить TTI в мілісекундах, а також дає конкретні рекомендації щодо покращення. Для безперервного моніторингу використовується PageSpeed Insights (Google) — він збирає дані з Chrome User Experience Report (CrUX) від реальних користувачів. У нативних додатках TTI вимірюється через Android Vitals (Google Play Console) та MetricKit (Apple).

Для продакшн-моніторингу популярні Firebase Performance Monitoring (спеціальні trace), Datadog RUM (Real User Monitoring) та Sentry Performance. Ці інструменти не тільки показують TTI, але й дозволяють простежити кореляцію між TTI та бізнес-метриками — конверсією, відтоком, часом сесії. Рекомендується встановити порогові значення: < 3.8 с — добре, 3.8–7 с — потребує покращення, > 7 с — критично. Для нативних додатків пороги суворіші: < 2 с — добре, 2–5 с — середньо, > 5 с — критично, оскільки користувачі мобільних додатків менш терпимі до затримок.

Налаштування Lighthouse CI

Приклад конфігурації Lighthouse CI для автоматичної перевірки TTI в CI/CD пайплайні. При перевищенні порогу 3.8 секунди збірка позначається попередженням.

// lighthouserc.js
module.exports = {
    ci: {
        assert: {
            assertions: {
                'interactive': ['warn', {
                    maxNumericValue: 3800
                }],
                'first-contentful-paint': ['error', {
                    maxNumericValue: 1800
                }]
            }
        },
        collect: {
            startServerCommand: 'npm start',
            url: ['http://localhost:3000'],
            numberOfRuns: 3
        }
    }
};