Time-to-Interactive in mobiele ontwikkeling: wat is het, metriek en metingen

Wat is Time-to-Interactive

Time-to-Interactive is een prestatiemetriek die het moment vastlegt waarop de pagina of applicatie klaar is voor volledige interactie met de gebruiker. In de webcontext wordt TTI gedefinieerd als de tijd vanaf het begin van de navigatie tot het moment waarop aan drie voorwaarden is voldaan: de pagina heeft nuttige inhoud weergegeven (First Contentful Paint), de hoofdthread was gedurende ten minste 5 seconden vrij en alle gebeurtenislisteners zijn geregistreerd. In mobiele apps is TTI de tijd vanaf het starten van een Activity tot de volledige initialisatie van de UI, wanneer alle toestanden zijn geladen, animaties zijn ingesteld en de gebruiker zonder vertraging op elke knop kan klikken.

De metriek is vooral belangrijk voor apps waar de eerste interactie cruciaal is — inlogschermen, zoeken, bestellen. Als TTI langer dan 5 seconden duurt, ervaart de gebruiker de app als “bevroren” en kan deze sluiten. Volgens gegevens van Google (Web Vitals Report, 2025) tonen pagina’s met een TTI van minder dan 3.8 seconden 24% meer conversies dan pagina’s met een TTI van meer dan 7 seconden. Het verschil is zelfs bij 500 ms voelbaar — Amazon-onderzoeken tonen een omzetverlies van 1% voor elke 100 ms vertraging.

Hoe wordt TTI berekend

Het algoritme voor het berekenen van TTI is gedefinieerd in de W3C-specificatie en geïmplementeerd in de Lighthouse-tool. De berekening begint met First Contentful Paint (FCP) — het moment waarop de browser de eerste pixel van inhoud heeft weergegeven. Vervolgens zoekt het algoritme naar een “stiltevenster” — een tijdsinterval van 5 seconden waarin er geen taken langer dan 50 ms op de hoofdthread waren. TTI wordt geregistreerd op de laatste taak voor dit venster. Als er binnen 15 seconden geen stiltevenster wordt gevonden, wordt TTI gelijkgesteld aan de tijd van de laatste lange taak. Dit algoritme garandeert dat TTI de werkelijke gereedheid voor interactie weerspiegelt, niet alleen het moment van rendering.

In mobiele apps (Android/iOS) is er geen exacte analoog van de W3C-specificatie, maar het concept is hetzelfde. TTI kan worden gemeten door een tijdstempel vast te leggen in onResume (start van de app) en in de callback van het eerste frame wanneer alle asynchrone bewerkingen zijn voltooid. De Firebase Performance-bibliotheek maakt het mogelijk om een aangepaste trace te definiëren met het begin en einde van een interactieve gebruikerssessie. Bijvoorbeeld startTrace(”tti”) in Application.onCreate en stopTrace() na voltooiing van de initialisatie van alle SDK’s en rendering van het eerste frame.

Voorbeeld van aangepaste trace voor TTI

Code in Kotlin toont het meten van TTI via Firebase Performance. De trace begint in Application.onCreate en stopt na de eerste 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 en FID: verschillen

In het Core Web Vitals-ecosysteem bestaan verschillende metrieken en TTI wordt vaak verward met First Contentful Paint (FCP) en Largest Contentful Paint (LCP). FCP is de tijd van de eerste pixel van inhoud, die geen interactiviteit garandeert. LCP is de tijd van het grootste inhoudselement (afbeelding, tekstblok). TTI meet echter niet de rendering, maar de gereedheid voor interactie. Het verschil is cruciaal: FCP kan 1.2 seconden zijn, maar als de hoofdthread wordt geblokkeerd door het laden van een JS-bundle, kan TTI 8 seconden bedragen.

First Input Delay (FID) meet de vertraging tussen de eerste actie van de gebruiker en het moment waarop de browser de gebeurtenis begint te verwerken. FID is de “kwaliteit van interactiviteit”, terwijl TTI de “tijd tot interactiviteit” is. Als TTI aangeeft na hoeveel seconden de interface responsief werd, geeft FID aan hoe responsief deze was. Een goede TTI zonder goede FID is onmogelijk, omdat als de hoofdthread geblokkeerd is, TTI hoog zal zijn en FID — elke interactie wordt vertraagd. In mobiele apps is de analoog van FID Touch Latency — de vertraging tussen het aanraken van het scherm en de UI-reactie.

TTI in mobiele apps

In native mobiele apps is het concept TTI niet zo gestandaardiseerd als op het web, maar het belang ervan is niet minder. In Android is TTI de tijd vanaf het klikken op het app-pictogram tot het moment waarop de UI volledig interactief is: RecyclerView scrollt, knoppen reageren op aanrakingen, animaties werken zonder haperingen. Voor het meten van TTI in Android wordt een combinatie van reportFullyDrawn (API 29+) en FrameMetricsAggregator gebruikt. reportFullyDrawn is een aanroep die de app doet op het moment dat de ontwikkelaar de UI als gereed beschouwt. Het systeem legt dit moment vast en neemt het op in het Android Vitals-rapport.

In iOS is de analoog van TTI de metrieken Time to First Frame en Time to Responsive. MetricKit verzamelt gegevens over de opstarttijd, onderverdeeld in fasen — laden van het uitvoerbare bestand, initialisatie van frameworks, rendering van het eerste frame. Apple raadt aan dat Time to First Frame niet meer dan 400 ms bedraagt en dat volledige interactiviteit binnen 2 seconden wordt bereikt. Als de app een placeholder-scherm toont en vervolgens inhoud laadt, wordt TTI niet berekend op basis van het eerste frame, maar op het moment waarop de werkelijke inhoud klaar is voor interactie.

TTI meten in Android via FrameMetrics

Code in Kotlin volgt het eerste interactieve frame met behulp van FrameMetricsAggregator. De callback wordt geactiveerd na voltooiing van het eerste frame dat door de gebruiker is geïnitieerd.

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", "Tijd tot interactiviteit: $ttiMs ms")
        metrics.reset()
    }
}

Optimalisatiemethoden voor TTI

Optimalisatie van TTI omvat drie richtingen: vermindering van de werklast in de hoofdthread, uitgesteld laden van niet-kritieke componenten en progressieve rendering. De eerste richting — minimalisatie van synchrone bewerkingen: vervanging van SharedPreferences door DataStore, verplaatsing van SDK-initialisatie naar een achtergrondthread, lazy laden van Dagger/Hilt-modules. De tweede — uitgesteld laden: schermen die bij het starten niet zichtbaar zijn (bottom sheets, dialoogvensters, tabbladen) moeten na het eerste frame worden geïnitialiseerd. De derde — progressieve rendering: eerst wordt een skeletonscherm getoond, vervolgens wordt de inhoud in delen geladen.

In Android is een effectieve methode het gebruik van de App Startup-bibliotheek met rangschikking van initializers. Bijvoorbeeld de initializer van Firebase Analytics kan optioneel worden gemaakt en de uitvoering ervan kan 2 seconden na het starten worden uitgesteld. In iOS is de analoog Initialization Dependencies met de vlag lazy. Voor het web zijn de belangrijkste methoden code splitting (splitsen van de bundle), tree shaking (verwijderen van dode code), preload/preconnect voor kritieke bronnen en defer voor niet-blokkerend JS. Google Lighthouse geeft specifieke aanbevelingen: ”Eliminate render-blocking resources” en ”Defer offscreen images” hebben direct invloed op TTI.

Code splitting in React Native

Voorbeeld van het splitsen van de bundle in React Native met React.lazy en Suspense. De component HeavyScreen wordt alleen geladen wanneer de gebruiker naar dit scherm navigeert, waardoor de TTI van het startscherm wordt verlaagd.

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

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

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

Hulpmiddelen voor het meten van TTI

Voor het meten van TTI bestaan verschillende hulpmiddelen die verschillen per platform en analysediepte. Op het web is het belangrijkste hulpmiddel Lighthouse in Chrome DevTools. Lighthouse voert een audit uit en geeft TTI in milliseconden weer, samen met specifieke aanbevelingen voor verbetering. Voor continue monitoring wordt PageSpeed Insights (Google) gebruikt — het verzamelt gegevens uit de Chrome User Experience Report (CrUX) van echte gebruikers. In native apps wordt TTI gemeten via Android Vitals (Google Play Console) en MetricKit (Apple).

Voor productiemonitoring zijn Firebase Performance Monitoring (custom traces), Datadog RUM (Real User Monitoring) en Sentry Performance populair. Deze tools tonen niet alleen TTI, maar maken ook het volgen van correlatie tussen TTI en bedrijfsmetrieken mogelijk — conversie, churn, sessieduur. Het wordt aanbevolen om drempelwaarden in te stellen: < 3.8 s — goed, 3.8–7 s — verbetering nodig, > 7 s — kritiek. Voor native apps zijn de drempels strenger: < 2 s — goed, 2–5 s — gemiddeld, > 5 s — kritiek, omdat gebruikers van mobiele apps minder tolerant zijn voor vertragingen.

Lighthouse CI-configuratie

Voorbeeld van Lighthouse CI-configuratie voor automatische controle van TTI in de CI/CD-pipeline. Bij overschrijding van de drempel van 3.8 seconden wordt de build gemarkeerd met een waarschuwing.

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