Time-to-Interactive in der mobilen Entwicklung: Was es ist, Metrik und Messung

Was ist Time-to-Interactive

Time-to-Interactive ist eine Leistungskennzahl, die den Moment erfasst, in dem eine Seite oder Anwendung für die vollständige Benutzerinteraktion bereit ist. Im Web-Kontext wird TTI als die Zeit vom Beginn der Navigation bis zu dem Moment definiert, an dem drei Bedingungen erfüllt sind: Die Seite hat nützlichen Inhalt angezeigt (First Contentful Paint), der Hauptthread war mindestens 5 Sekunden lang im Leerlauf, und alle Ereignis-Listener sind registriert. In mobilen Anwendungen ist TTI die Zeit vom Start der Activity bis zur vollständigen UI-Initialisierung, wenn alle Zustände geladen, Animationen konfiguriert sind und der Benutzer ohne Verzögerung auf jede Schaltfläche tippen kann.

Diese Kennzahl ist besonders wichtig für Anwendungen, bei denen die erste Interaktion entscheidend ist — Anmeldebildschirme, Suche, Kaufabwicklung. Wenn TTI 5 Sekunden überschreitet, nimmt der Benutzer die App als „eingefroren“ wahr und schließt sie möglicherweise. Laut Google (Web Vitals Report, 2025) erzielen Seiten mit einem TTI unter 3,8 Sekunden 24% mehr Conversions als Seiten mit einem TTI über 7 Sekunden. Der Unterschied ist bereits bei 500 ms spürbar — Amazon-Studien zeigen einen Umsatzverlust von 1% pro 100 ms Verzögerung.

Wie TTI berechnet wird

Der Algorithmus zur Berechnung von TTI ist in der W3C-Spezifikation definiert und in Lighthouse implementiert. Die Berechnung beginnt mit First Contentful Paint (FCP) — dem Moment, in dem der Browser das erste Pixel des Inhalts rendert. Anschließend sucht der Algorithmus nach einem „Ruhefenster“ — einem Zeitraum von 5 Sekunden, in dem keine Aufgabe im Hauptthread länger als 50 ms dauert. TTI wird auf die letzte Aufgabe vor diesem Fenster gesetzt. Wenn innerhalb von 15 Sekunden kein Ruhefenster gefunden wird, wird TTI auf die Zeit der letzten langen Aufgabe gesetzt. Dieser Algorithmus stellt sicher, dass TTI die tatsächliche Bereitschaft zur Interaktion widerspiegelt, nicht nur den Rendering-Zeitpunkt.

In mobilen Anwendungen (Android/iOS) gibt es kein genaues Äquivalent zur W3C-Spezifikation, aber das Konzept ist dasselbe. TTI kann gemessen werden, indem ein Zeitstempel in onResume (Startbeginn) und im Callback des ersten Frames erfasst wird, wenn alle asynchronen Vorgänge abgeschlossen sind. Firebase Performance ermöglicht die Erstellung eines benutzerdefinierten Trace mit Start und Ende der interaktiven Benutzersitzung. Zum Beispiel startTrace(„TTI“) in Application.onCreate und stopTrace(), nachdem alle SDKs initialisiert und der erste Frame gerendert wurde.

Beispiel für einen benutzerdefinierten Trace für TTI

Kotlin-Code demonstriert die TTI-Messung mit Firebase Performance. Der Trace beginnt in Application.onCreate und stoppt nach dem ersten 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 und FID: Unterschiede

Im Core Web Vitals-Ökosystem gibt es mehrere Metriken, und TTI wird oft mit First Contentful Paint (FCP) und Largest Contentful Paint (LCP) verwechselt. FCP ist die Zeit für das erste Pixel des Inhalts, die keine Interaktivität garantiert. LCP ist die Renderzeit des größten Inhaltselements (Bild, Textblock). TTI misst jedoch nicht das Rendering, sondern die Bereitschaft zur Interaktion. Der Unterschied ist entscheidend: FCP kann 1,2 Sekunden betragen, aber wenn der Hauptthread durch das Laden des JS-Bundles blockiert ist, kann TTI 8 Sekunden erreichen.

First Input Delay (FID) misst die Verzögerung zwischen der ersten Aktion des Benutzers und dem Moment, in dem der Browser mit der Verarbeitung des Ereignisses beginnt. FID ist die „Qualität der Interaktivität“, während TTI die „Zeit bis zur Interaktivität“ ist. Wenn TTI anzeigt, in wie vielen Sekunden die Oberfläche reagiert, zeigt FID, wie reaktionsfähig sie war. Ein guter TTI ist ohne guten FID unmöglich, denn wenn der Hauptthread blockiert ist, wird TTI hoch sein und FID jede Interaktion verzögern. In mobilen Anwendungen ist das Äquivalent zu FID die Touch Latency — die Verzögerung zwischen dem Berühren des Bildschirms und der UI-Reaktion.

TTI in mobilen Anwendungen

In nativen mobilen Anwendungen ist das Konzept von TTI nicht so standardisiert wie im Web, aber seine Bedeutung ist nicht geringer. Unter Android ist TTI die Zeit vom Tippen auf das App-Symbol bis zu dem Moment, in dem die UI vollständig interaktiv ist: RecyclerView scrollt, Schaltflächen reagieren auf Berührungen, Animationen laufen reibungslos. Zur Messung von TTI unter Android wird eine Kombination aus reportFullyDrawn (API 29+) und FrameMetricsAggregator verwendet. reportFullyDrawn ist ein Aufruf, den die App tätigt, wenn der Entwickler die UI als bereit betrachtet. Das System erfasst diesen Moment und nimmt ihn in den Android Vitals-Bericht auf.

Unter iOS sind die Äquivalente zu TTI Time to First Frame und Time to Responsive. MetricKit sammelt Startzeitdaten, aufgeschlüsselt in Phasen — Laden der ausführbaren Datei, Framework-Initialisierung, Rendern des ersten Frames. Apple empfiehlt, dass Time to First Frame 400 ms nicht überschreiten sollte und die vollständige Interaktivität innerhalb von 2 Sekunden erreicht wird. Wenn die App einen Platzhalterbildschirm anzeigt und dann Inhalte lädt, wird TTI nicht ab dem ersten Frame berechnet, sondern ab dem Moment, in dem der tatsächliche Inhalt für die Interaktion bereit ist.

Messung von TTI unter Android mit FrameMetrics

Kotlin-Code verfolgt den ersten interaktiven Frame mit FrameMetricsAggregator. Der Callback wird ausgelöst, nachdem der erste vom Benutzer initiierte Frame abgeschlossen ist.

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", "Time to Interactive: $ttiMs ms")
        metrics.reset()
    }
}

Methoden zur TTI-Optimierung

Die Optimierung von TTI umfasst drei Richtungen: Reduzierung der Arbeitslast im Hauptthread, verzögertes Laden nicht kritischer Komponenten und progressives Rendern. Die erste Richtung ist die Minimierung synchroner Operationen: Ersetzen von SharedPreferences durch DataStore, Verschieben der SDK-Initialisierung in einen Hintergrundthread, verzögertes Laden von Dagger/Hilt-Modulen. Die zweite ist das verzögerte Laden: Bildschirme, die beim Start nicht sichtbar sind (Bottom Sheets, Dialoge, Tabs), sollten nach dem ersten Frame initialisiert werden. Die dritte ist das progressive Rendern: Zuerst einen Skelettbildschirm anzeigen, dann den Inhalt in Teilen laden.

Unter Android ist eine effektive Methode die Verwendung der App Startup-Bibliothek mit gestaffelten Initialisierern. Zum Beispiel kann der Firebase Analytics-Initialisierer optional gemacht und um 2 Sekunden nach dem Start verzögert werden. Unter iOS ist das Äquivalent Initialization Dependencies mit dem lazy-Flag. Für das Web sind die wichtigsten Methoden Code Splitting, Tree Shaking, Preload/Preconnect für kritische Ressourcen und defer für nicht blockierendes JS. Google Lighthouse gibt spezifische Empfehlungen: „Eliminate render-blocking resources“ und „Defer offscreen images“ wirken sich direkt auf TTI aus.

Code Splitting in React Native

Beispiel für die Bundle-Aufteilung in React Native mit React.lazy und Suspense. Die Komponente HeavyScreen wird nur geladen, wenn der Benutzer zu diesem Bildschirm navigiert, wodurch der TTI des Startbildschirms reduziert wird.

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

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

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

Werkzeuge zur TTI-Messung

Es stehen mehrere Werkzeuge zur Messung von TTI zur Verfügung, die sich je nach Plattform und Analysetiefe unterscheiden. Im Web ist das primäre Werkzeug Lighthouse in den Chrome DevTools. Lighthouse führt einen Audit durch und gibt TTI in Millisekunden aus, zusammen mit spezifischen Empfehlungen zur Verbesserung. Für die kontinuierliche Überwachung wird PageSpeed Insights (Google) verwendet — es sammelt Daten aus dem Chrome User Experience Report (CrUX) von echten Benutzern. In nativen Apps wird TTI über Android Vitals (Google Play Console) und MetricKit (Apple) gemessen.

Für das Produktionsmonitoring sind beliebte Werkzeuge Firebase Performance Monitoring (benutzerdefinierte Traces), Datadog RUM (Real User Monitoring) und Sentry Performance. Diese Werkzeuge zeigen nicht nur TTI an, sondern ermöglichen auch die Verfolgung der Korrelation zwischen TTI und Geschäftskennzahlen — Conversion, Abwanderung, Sitzungsdauer. Empfohlene Schwellenwerte: < 3,8 s — gut, 3,8–7 s — verbesserungswürdig, > 7 s — kritisch. Für native Apps sind die Schwellenwerte strenger: < 2 s — gut, 2–5 s — mittel, > 5 s — kritisch, da mobile App-Benutzer weniger tolerant gegenüber Verzögerungen sind.

Lighthouse CI-Konfiguration

Beispiel für die Konfiguration von Lighthouse CI zur automatischen TTI-Überprüfung in einer CI/CD-Pipeline. Wenn der Schwellenwert von 3,8 Sekunden überschritten wird, wird der Build mit einer Warnung markiert.

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