Time-to-Interactive в мобильной разработке: что это такое, метрика и замеры

Что такое Time-to-Interactive

Time-to-Interactive — это метрика производительности, которая фиксирует момент, когда страница или приложение готово к полноценному взаимодействию с пользователем. В контексте веба TTI определяется как время от начала навигации до момента, когда выполняются три условия: страница отобразила полезный контент (First Contentful Pyramid), основная нить была свободна в течение как минимум 5 секунд и все listener-ы событий зарегистрированы. В мобильных приложениях 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 (начало запуска) и в колбэке первого фрейма, когда все async-операции завершены. Библиотека Firebase Performance позволяет задать custom trace с началом и концом пользовательской интерактивной сессии. Например, startTrace("tti") в Application.onCreate и stopTrace() после завершения инициализации всех SDK и отрисовки первого фрейма.

Пример custom 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 секунд. Если приложение показывает placeholder-экран, а затем подгружает контент, 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 включает три направления: сокращение объёма работы в main thread, отложенная загрузка некритичных компонентов и прогрессивный рендеринг. Первое направление — минимизация синхронных операций: замена 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 (custom traces), 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
        }
    }
};