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 ms — изследванията на Amazon показват загуба на 1% от приходите за всеки 100 ms забавяне.

Как се изчислява TTI

Алгоритъмът за изчисляване на TTI е дефиниран в спецификацията на W3C и е имплементиран в инструмента Lighthouse. Изчислението започва с First Contentful Paint (FCP) — момента, в който браузърът е рендирал първия пиксел от съдържанието. След това алгоритъмът търси ”прозорец на тишина” — времеви интервал от 5 секунди, в който не е имало задачи, по-дълги от 50 ms на основната нишка. TTI се записва на последната задача преди този прозорец. Ако прозорец на тишина не бъде намерен до 15 секунди, TTI се счита за равен на времето на последната дълга задача. Този алгоритъм гарантира, че TTI отразява реалната готовност за взаимодействие, а не просто момента на рендиране.

В мобилните приложения (Android/iOS) няма точен аналог на спецификацията на W3C, но концепцията е същата. TTI може да се измери чрез записване на времеви клей в onResume (начало на стартиране) и в callback на първия кадър, когато всички асинхронни операции са завършени. Библиотеката 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 ms, а пълна интерактивност да се постигне в рамките на 2 секунди. Ако приложението показва екран за placeholder и след това зарежда съдържание, TTI се изчислява не според първия кадър, а според момента, в който реалното съдържание е готово за взаимодействие.

Измерване на TTI в Android чрез FrameMetrics

Код на Kotlin проследява първия интерактивен кадър с помощта на FrameMetricsAggregator. Callback се активира след завършване на първия кадър, иницииран от потребителя.

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", "Време до интерактивност: $ttiMs ms")
        metrics.reset()
    }
}

Методи за оптимизация на TTI

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

В 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
        }
    }
};