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 — Амазонова истраживања показују губитак од 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
        }
    }
};