Time-to-Interactive inom mobilutveckling: vad är det, metriken och mätningar

Vad är Time-to-Interactive

Time-to-Interactive är en prestandamätning som registrerar det ögonblick då sidan eller applikationen är redo för full interaktion med användaren. I webbkontext definieras TTI som tiden från navigationsstart till det ögonblick då tre villkor är uppfyllda: sidan har visat användbart innehåll (First Contentful Paint), huvudtråden har varit ledig i minst 5 sekunder och alla händelseavlyssnare har registrerats. I mobila applikationer är TTI tiden från start av en Activity till fullständig initiering av UI, när alla tillstånd är laddade, animationer är konfigurerade och användaren kan klicka på valfri knapp utan fördröjning.

Metriken är särskilt viktig för applikationer där den första interaktionen är kritisk — inloggningsskärmar, sökning, beställning. Om TTI överstiger 5 sekunder uppfattar användaren applikationen som ”frusen” och kan stänga den. Enligt Googles data (Web Vitals Report, 2025) visar sidor med TTI lägre än 3,8 sekunder 24% fler konverteringar än sidor med TTI högre än 7 sekunder. Skillnaden märks redan vid 500 ms — Amazons forskning visar en intäktsförlust på 1% för varje 100 ms fördröjning.

Hur beräknas TTI

Algoritmen för beräkning av TTI är definierad i W3C-specifikationen och implementerad i verktyget Lighthouse. Beräkningen börjar med First Contentful Paint (FCP) — det ögonblick då webbläsaren renderade den första pixeln av innehåll. Därefter söker algoritmen efter ett ”tystnadsfönster” — ett tidsintervall på 5 sekunder under vilket det inte fanns några uppgifter längre än 50 ms på huvudtråden. TTI registreras vid den sista uppgiften före detta fönster. Om inget tystnadsfönster hittas inom 15 sekunder anses TTI vara lika med tiden för den sista långa uppgiften. Denna algoritm garanterar att TTI återspeglar verklig beredskap för interaktion, inte bara renderingsögonblicket.

I mobila applikationer (Android/iOS) finns ingen exakt motsvarighet till W3C-specifikationen, men konceptet är detsamma. TTI kan mätas genom att registrera en tidsstämpel i onResume (start av lansering) och i callback för den första bildrutan när alla asynkrona operationer är slutförda. Firebase Performance-biblioteket möjliggör definition av en anpassad trace med början och slut på en interaktiv användarsession. Till exempel startTrace(”tti”) i Application.onCreate och stopTrace() efter slutförd initiering av alla SDK:er och rendering av den första bildrutan.

Exempel på anpassad trace för TTI

Kod i Kotlin visar mätning av TTI via Firebase Performance. Trace börjar i Application.onCreate och stoppas efter den första 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 och FID: skillnader

I Core Web Vitals-ekosystemet finns flera mätvärden och TTI förväxlas ofta med First Contentful Paint (FCP) och Largest Contentful Paint (LCP). FCP är tiden för rendering av den första innehållspixeln, vilket inte garanterar interaktivitet. LCP är tiden för rendering av det största innehållselementet (bild, textblock). TTI mäter dock inte rendering, utan beredskap för interaktion. Skillnaden är kritisk: FCP kan vara 1,2 sekunder, men om huvudtråden blockeras av laddning av JS-paketet kan TTI nå 8 sekunder.

First Input Delay (FID) mäter fördröjningen mellan användarens första åtgärd och det ögonblick då webbläsaren började bearbeta händelsen. FID är ”kvaliteten på interaktivitet” medan TTI är ”tiden till interaktivitet”. Om TTI visar efter hur många sekunder gränssnittet blev responsivt, visar FID hur responsivt det var. Bra TTI utan bra FID är omöjligt, för om huvudtråden är blockerad kommer TTI att vara högt och FID — varje interaktion kommer att försenas. I mobila applikationer är motsvarigheten till FID Touch Latency — fördröjningen mellan beröring av skärmen och UI-reaktion.

TTI i mobila applikationer

I inbyggda mobila applikationer är konceptet TTI inte lika standardiserat som på webben, men dess betydelse är inte mindre. I Android är TTI tiden från klick på appikonen till det ögonblick då UI är fullt interaktivt: RecyclerView rullar, knappar reagerar på beröring, animationer fungerar utan hackning. För mätning av TTI i Android används en kombination av reportFullyDrawn (API 29+) och FrameMetricsAggregator. reportFullyDrawn är ett anrop som applikationen gör i det ögonblick då utvecklaren anser UI vara klart. Systemet registrerar detta ögonblick och inkluderar det i Android Vitals-rapporten.

I iOS är motsvarigheten till TTI mätvärdena Time to First Frame och Time to Responsive. MetricKit samlar in data om starttid uppdelad i faser — laddning av körbar fil, initiering av ramverk, rendering av första bildrutan. Apple rekommenderar att Time to First Frame inte överstiger 400 ms och full interaktivitet uppnås inom 2 sekunder. Om applikationen visar en platshållarskärm och sedan laddar innehåll, beräknas TTI inte baserat på den första bildrutan utan baserat på det ögonblick då det verkliga innehållet är redo för interaktion.

Mätning av TTI i Android via FrameMetrics

Kod i Kotlin spårar den första interaktiva bildrutan med hjälp av FrameMetricsAggregator. Callback aktiveras efter slutförande av den första bildrutan som initierats av användaren.

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", "Tid till interaktivitet: $ttiMs ms")
        metrics.reset()
    }
}

Optimeringsmetoder för TTI

Optimering av TTI omfattar tre riktningar: minskning av arbetsmängden i huvudtråden, fördröjd laddning av icke-kritiska komponenter och progressiv rendering. Första riktningen — minimering av synkrona operationer: ersättning av SharedPreferences med DataStore, flyttning av SDK-initiering till bakgrundstråd, lat laddning av Dagger/Hilt-moduler. Andra — fördröjd laddning: skärmar som inte är synliga vid start (bottenblad, dialoger, flikar) bör initieras efter den första bildrutan. Tredje — progressiv rendering: först visas en skelettskärm, sedan laddas innehållet i delar.

I Android är en effektiv metod att använda App Startup-biblioteket med rangordning av initierare. Till exempel kan initieraren av Firebase Analytics göras valfri och dess exekvering fördröjas med 2 sekunder efter start. I iOS är motsvarigheten Initialization Dependencies med flaggan lazy. För webben är de viktigaste metoderna code splitting (delning av paket), tree shaking (borttagning av död kod), preload/preconnect för kritiska resurser och defer för icke-blockerande JS. Google Lighthouse ger specifika rekommendationer: ”Eliminate render-blocking resources” och ”Defer offscreen images” påverkar direkt TTI.

Code splitting i React Native

Exempel på delning av paket i React Native med React.lazy och Suspense. Komponenten HeavyScreen laddas endast när användaren navigerar till denna skärm, vilket minskar TTI för startsidan.

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

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

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

Verktyg för att mäta TTI

För mätning av TTI finns flera verktyg som skiljer sig åt beroende på plattform och analysdjup. På webben är huvudverktyget Lighthouse i Chrome DevTools. Lighthouse kör en granskning och visar TTI i millisekunder, samt ger specifika rekommendationer för förbättring. För kontinuerlig övervakning används PageSpeed Insights (Google) — det samlar in data från Chrome User Experience Report (CrUX) från verkliga användare. I inbyggda applikationer mäts TTI via Android Vitals (Google Play Console) och MetricKit (Apple).

För produktionsövervakning är Firebase Performance Monitoring (custom traces), Datadog RUM (Real User Monitoring) och Sentry Performance populära. Dessa verktyg visar inte bara TTI, utan möjliggör även spårning av korrelation mellan TTI och affärsmått — konvertering, churn, sessionstid. Det rekommenderas att sätta tröskelvärden: < 3,8 s — bra, 3,8–7 s — kräver förbättring, > 7 s — kritiskt. För inbyggda applikationer är trösklarna strängare: < 2 s — bra, 2–5 s — medel, > 5 s — kritiskt, eftersom användare av mobila applikationer är mindre toleranta mot fördröjningar.

Lighthouse CI-konfiguration

Exempel på konfiguration av Lighthouse CI för automatisk kontroll av TTI i CI/CD-pipelinen. Vid överskridande av tröskeln 3,8 sekunder markeras bygget med en varning.

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