Time-to-Interactive în dezvoltarea mobilă: ce este, metrica și măsurători

Ce este Time-to-Interactive

Time-to-Interactive este o metrică de performanță care înregistrează momentul în care pagina sau aplicația este gata pentru interacțiunea completă cu utilizatorul. În contextul web, TTI este definit ca timpul de la începutul navigării până în momentul în care sunt îndeplinite trei condiții: pagina a afișat conținut util (First Contentful Paint), firul principal a fost liber timp de cel puțin 5 secunde și toate ascultătoarele de evenimente au fost înregistrate. În aplicațiile mobile, TTI este timpul de la lansarea Activity până la inițializarea completă a UI, când toate stările sunt încărcate, animațiile sunt configurate și utilizatorul poate apăsa orice buton fără întârziere.

Metrica este deosebit de importantă pentru aplicațiile în care prima interacțiune este critică — ecranele de autentificare, căutare, plasare a comenzii. Dacă TTI depășește 5 secunde, utilizatorul percepe aplicația ca „înghețată” și o poate închide. Conform datelor Google (Web Vitals Report, 2025), paginile cu TTI mai mic de 3.8 secunde arată cu 24% mai multe conversii decât paginile cu TTI mai mare de 7 secunde. Diferența se simte chiar și la 500 ms — cercetările Amazon arată o pierdere de 1% din venit pentru fiecare 100 ms de întârziere.

Cum se calculează TTI

Algoritmul de calcul al TTI este definit în specificația W3C și implementat în instrumentul Lighthouse. Calculul începe cu First Contentful Paint (FCP) — momentul în care browserul a randat primul pixel de conținut. Apoi algoritmul caută o „fereastră de liniște” — un interval de timp de 5 secunde în care nu au existat sarcini mai lungi de 50 ms pe firul principal. TTI este înregistrat la ultima sarcină înainte de această fereastră. Dacă fereastra de liniște nu este găsită până la 15 secunde, TTI este considerat egal cu timpul ultimei sarcini lungi. Acest algoritm garantează că TTI reflectă disponibilitatea reală pentru interacțiune, nu doar momentul randării.

În aplicațiile mobile (Android/iOS) nu există un analog exact al specificației W3C, dar conceptul este același. TTI poate fi măsurat prin înregistrarea unui marcaj temporal în onResume (începutul lansării) și în callback-ul primului cadru, când toate operațiunile asincrone sunt finalizate. Biblioteca Firebase Performance permite definirea unui trace personalizat cu începutul și sfârșitul sesiunii interactive a utilizatorului. De exemplu, startTrace(”tti”) în Application.onCreate și stopTrace() după finalizarea inițializării tuturor SDK-urilor și randarea primului cadru.

Exemplu de trace personalizat pentru TTI

Codul în Kotlin demonstrează măsurarea TTI prin Firebase Performance. Trace începe în Application.onCreate și se oprește după primul 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 și FID: diferențe

În ecosistemul Core Web Vitals există mai multe metrici și TTI este adesea confundat cu First Contentful Paint (FCP) și Largest Contentful Paint (LCP). FCP este timpul de randare a primului pixel de conținut, care nu garantează interactivitatea. LCP este timpul de randare a celui mai mare element de conținut (imagine, bloc de text). TTI însă măsoară nu randarea, ci disponibilitatea pentru interacțiune. Diferența este critică: FCP poate fi de 1.2 secunde, dar dacă firul principal este blocat de încărcarea pachetului JS, TTI poate ajunge la 8 secunde.

First Input Delay (FID) măsoară întârzierea dintre prima acțiune a utilizatorului și momentul în care browserul a început procesarea evenimentului. FID este „calitatea interactivității”, iar TTI este „timpul până la interactivitate”. Dacă TTI arată după câte secunde interfața a devenit receptivă, FID arată cât de receptivă a fost. Un TTI bun fără un FID bun este imposibil, deoarece dacă firul principal este blocat, TTI va fi ridicat, iar FID — orice interacțiune va fi întârziată. În aplicațiile mobile, analogul FID este Touch Latency — întârzierea dintre atingerea ecranului și reacția UI.

TTI în aplicațiile mobile

În aplicațiile mobile native, conceptul TTI nu este la fel de standardizat ca în web, dar importanța sa nu este mai mică. În Android, TTI este timpul de la clic pe pictograma aplicației până în momentul în care UI este complet interactiv: RecyclerView se derulează, butoanele reacționează la atingeri, animațiile funcționează fără întreruperi. Pentru măsurarea TTI în Android se utilizează combinația dintre reportFullyDrawn (API 29+) și FrameMetricsAggregator. reportFullyDrawn este o apelare pe care aplicația o face în momentul în care dezvoltatorul consideră UI-ul gata. Sistemul înregistrează acest moment și îl include în raportul Android Vitals.

În iOS, analogul TTI sunt metricele Time to First Frame și Time to Responsive. MetricKit colectează datele despre timpul de lansare defalcate pe faze — încărcarea fișierului executabil, inițializarea framework-urilor, randarea primului cadru. Apple recomandă ca Time to First Frame să nu depășească 400 ms, iar interactivitatea completă să fie atinsă în 2 secunde. Dacă aplicația afișează un ecran placeholder și apoi încarcă conținutul, TTI se calculează nu după primul cadru, ci după momentul în care conținutul real este gata pentru interacțiune.

Măsurarea TTI în Android prin FrameMetrics

Codul în Kotlin urmărește primul cadru interactiv cu ajutorul FrameMetricsAggregator. Callback-ul se activează după finalizarea primului cadru inițiat de utilizator.

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", "Timp până la interactivitate: $ttiMs ms")
        metrics.reset()
    }
}

Metode de optimizare TTI

Optimizarea TTI include trei direcții: reducerea volumului de lucru în firul principal, încărcarea amânată a componentelor necritice și randarea progresivă. Prima direcție — minimizarea operațiunilor sincrone: înlocuirea SharedPreferences cu DataStore, mutarea inițializării SDK-urilor într-un fir de fundal, încărcarea leneșă a modulelor Dagger/Hilt. A doua — încărcarea amânată: ecranele care nu sunt vizibile la pornire (bottom sheets, dialoguri, file) ar trebui inițializate după primul cadru. A treia — randarea progresivă: mai întâi se afișează un ecran schelet, apoi conținutul se încarcă treptat.

În Android, o metodă eficientă este utilizarea bibliotecii App Startup cu clasificarea inițializatoarelor. De exemplu, inițializatorul Firebase Analytics poate fi făcut opțional și executarea sa poate fi amânată cu 2 secunde după pornire. În iOS, analogul este Initialization Dependencies cu flagul lazy. Pentru web, metodele cheie sunt code splitting (divizarea pachetului), tree shaking (eliminarea codului mort), preload/preconnect pentru resursele critice și defer pentru JS neblocant. Google Lighthouse oferă recomandări specifice: „Eliminate render-blocking resources” și „Defer offscreen images” influențează direct TTI.

Code splitting în React Native

Exemplu de divizare a pachetului în React Native cu ajutorul React.lazy și Suspense. Componenta HeavyScreen se încarcă doar atunci când utilizatorul navighează la acest ecran, reducând TTI-ul ecranului inițial.

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

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

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

Instrumente de măsurare TTI

Pentru măsurarea TTI există mai multe instrumente care diferă în funcție de platformă și profunzimea analizei. În web, instrumentul principal este Lighthouse în Chrome DevTools. Lighthouse rulează un audit și afișează TTI în milisecunde, oferind și recomandări specifice de îmbunătățire. Pentru monitorizarea continuă se utilizează PageSpeed Insights (Google) — colectează date din Chrome User Experience Report (CrUX) de la utilizatori reali. În aplicațiile native, TTI se măsoară prin Android Vitals (Google Play Console) și MetricKit (Apple).

Pentru monitorizarea în producție, populare sunt Firebase Performance Monitoring (custom traces), Datadog RUM (Real User Monitoring) și Sentry Performance. Aceste instrumente nu doar arată TTI, dar permit și urmărirea corelației dintre TTI și metricile de business — conversie, abandon, durata sesiunii. Se recomandă stabilirea valorilor de prag: < 3.8 s — bine, 3.8–7 s — necesită îmbunătățire, > 7 s — critic. Pentru aplicațiile native, pragurile sunt mai stricte: < 2 s — bine, 2–5 s — mediu, > 5 s — critic, deoarece utilizatorii aplicațiilor mobile sunt mai puțin toleranți la întârzieri.

Configurarea Lighthouse CI

Exemplu de configurare a Lighthouse CI pentru verificarea automată a TTI în pipeline-ul CI/CD. La depășirea pragului de 3.8 secunde, build-ul este marcat cu un avertisment.

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