Time-to-Interactive w rozwoju aplikacji mobilnych: co to jest, metryka i pomiary

Czym jest Time-to-Interactive

Time-to-Interactive to metryka wydajności, która rejestruje moment, gdy strona lub aplikacja jest gotowa do pełnej interakcji z użytkownikiem. W kontekście sieci TTI definiuje się jako czas od rozpoczęcia nawigacji do momentu, gdy spełnione są trzy warunki: strona wyświetliła użyteczną treść (First Contentful Paint), główny wątek był wolny przez co najmniej 5 sekund i wszystkie nasłuchiwacze zdarzeń zostały zarejestrowane. W aplikacjach mobilnych TTI to czas od uruchomienia Activity do pełnej inicjalizacji UI, gdy wszystkie stany są załadowane, animacje skonfigurowane, a użytkownik może kliknąć dowolny przycisk bez opóźnienia.

Metryka jest szczególnie ważna dla aplikacji, w których pierwsza interakcja jest krytyczna — ekrany logowania, wyszukiwania, składania zamówienia. Jeśli TTI przekracza 5 sekund, użytkownik postrzega aplikację jako „zawieszoną” i może ją zamknąć. Według danych Google (Web Vitals Report, 2025), strony z TTI poniżej 3.8 sekund wykazują o 24% więcej konwersji niż strony z TTI powyżej 7 sekund. Różnica jest odczuwalna nawet przy 500 ms — badania Amazon pokazują utratę 1% przychodu za każde 100 ms opóźnienia.

Jak oblicza się TTI

Algorytm obliczania TTI jest określony w specyfikacji W3C i zaimplementowany w narzędziu Lighthouse. Obliczanie zaczyna się od First Contentful Paint (FCP) — momentu, gdy przeglądarka wyrenderowała pierwszy piksel treści. Następnie algorytm szuka „okna ciszy” — przedziału czasu trwającego 5 sekund, w którym na głównym wątku nie było zadań dłuższych niż 50 ms. TTI jest rejestrowane na ostatnim zadaniu przed tym oknem. Jeśli okno ciszy nie zostanie znalezione do 15 sekund, TTI jest uznawane za równe czasowi ostatniego długiego zadania. Ten algorytm gwarantuje, że TTI odzwierciedla rzeczywistą gotowość do interakcji, a nie tylko moment renderowania.

W aplikacjach mobilnych (Android/iOS) nie ma dokładnego odpowiednika specyfikacji W3C, ale koncepcja jest taka sama. TTI można zmierzyć, rejestrując znacznik czasu w onResume (początek uruchamiania) i w callbacku pierwszej klatki, gdy wszystkie operacje asynchroniczne są zakończone. Biblioteka Firebase Performance pozwala zdefiniować custom trace z początkiem i końcem sesji interaktywnej użytkownika. Na przykład startTrace(”tti”) w Application.onCreate i stopTrace() po zakończeniu inicjalizacji wszystkich SDK i renderowaniu pierwszej klatki.

Przykład custom trace dla TTI

Kod w Kotlin demonstruje pomiar TTI przez Firebase Performance. Trace rozpoczyna się w Application.onCreate i zatrzymuje po pierwszym 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: różnice

W ekosystemie Core Web Vitals istnieje kilka metryk i TTI jest często mylone z First Contentful Paint (FCP) i Largest Contentful Paint (LCP). FCP to czas renderowania pierwszego piksela treści, który nie gwarantuje interaktywności. LCP to czas renderowania największego elementu treści (obrazu, bloku tekstu). TTI natomiast mierzy nie renderowanie, ale gotowość do interakcji. Różnica jest krytyczna: FCP może wynosić 1.2 sekundy, ale jeśli główny wątek jest zablokowany ładowaniem pakietu JS, TTI może osiągnąć 8 sekund.

First Input Delay (FID) mierzy opóźnienie między pierwszym działaniem użytkownika a momentem, gdy przeglądarka rozpoczęła przetwarzanie zdarzenia. FID to „jakość interaktywności”, a TTI to „czas do interaktywności”. Jeśli TTI pokazuje, po ilu sekundach interfejs stał się responsywny, to FID pokazuje, jak responsywny był. Dobry TTI bez dobrego FID jest niemożliwy, ponieważ jeśli główny wątek jest zablokowany, TTI będzie wysokie, a FID — każde działanie będzie opóźnione. W aplikacjach mobilnych odpowiednikiem FID jest Touch Latency — opóźnienie między dotknięciem ekranu a reakcją UI.

TTI w aplikacjach mobilnych

W natywnych aplikacjach mobilnych koncepcja TTI nie jest tak ustandaryzowana jak w sieci, ale jej znaczenie jest nie mniejsze. W Androidzie TTI to czas od kliknięcia ikony aplikacji do momentu, gdy UI jest w pełni interaktywny: RecyclerView przewija się, przyciski reagują na dotknięcia, animacje działają bez zacięć. Do pomiaru TTI w Androidzie używa się kombinacji reportFullyDrawn (API 29+) i FrameMetricsAggregator. reportFullyDrawn to wywołanie, które aplikacja wykonuje w momencie, gdy programista uzna UI za gotowy. System rejestruje ten moment i uwzględnia go w raporcie Android Vitals.

W iOS odpowiednikiem TTI jest metryka Time to First Frame i Time to Responsive. MetricKit zbiera dane o czasie uruchamiania z podziałem na fazy — ładowanie pliku wykonywalnego, inicjalizacja frameworków, renderowanie pierwszej klatki. Apple zaleca, aby Time to First Frame nie przekraczał 400 ms, a pełna interaktywność była osiągana w ciągu 2 sekund. Jeśli aplikacja wyświetla ekran zastępczy, a następnie ładuje treść, TTI liczy się nie od pierwszej klatki, ale od momentu, gdy rzeczywista treść jest gotowa do interakcji.

Pomiar TTI w Androidzie przez FrameMetrics

Kod w Kotlin śledzi pierwszą interaktywną klatkę za pomocą FrameMetricsAggregator. Callback uruchamia się po zakończeniu pierwszej klatki zainicjowanej przez użytkownika.

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", "Czas do interaktywności: $ttiMs ms")
        metrics.reset()
    }
}

Metody optymalizacji TTI

Optymalizacja TTI obejmuje trzy kierunki: zmniejszenie ilości pracy w głównym wątku, odroczone ładowanie niekrytycznych komponentów i progresywne renderowanie. Pierwszy kierunek — minimalizacja operacji synchronicznych: zamiana SharedPreferences na DataStore, przeniesienie inicjalizacji SDK do wątku tła, leniwe ładowanie modułów Dagger/Hilt. Drugi — odroczone ładowanie: ekrany, które nie są widoczne przy starcie (bottom sheets, dialogi, zakładki), powinny być inicjalizowane po pierwszej klatce. Trzeci — progresywne renderowanie: najpierw wyświetlany jest ekran szkieletowy, następnie treść jest ładowana partiami.

W Androidzie skuteczną metodą jest użycie biblioteki App Startup z szeregowaniem inicjalizatorów. Na przykład inicjalizator Firebase Analytics można uczynić opcjonalnym i odłożyć jego wykonanie o 2 sekundy po starcie. W iOS odpowiednikiem są Initialization Dependencies z flagą lazy. Dla sieci kluczowe metody to code splitting (podział pakietu), tree shaking (usuwanie martwego kodu), preload/preconnect dla krytycznych zasobów i defer dla nieblokującego JS. Google Lighthouse daje konkretne zalecenia: „Eliminate render-blocking resources” i „Defer offscreen images” bezpośrednio wpływają na TTI.

Code splitting w React Native

Przykład podziału pakietu w React Native za pomocą React.lazy i Suspense. Komponent HeavyScreen ładuje się tylko wtedy, gdy użytkownik przechodzi na ten ekran, zmniejszając TTI początkowego ekranu.

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

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

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

Narzędzia do pomiaru TTI

Do pomiaru TTI istnieje kilka narzędzi różniących się platformą i głębokością analizy. W sieci głównym narzędziem jest Lighthouse w Chrome DevTools. Lighthouse uruchamia audyt i wyświetla TTI w milisekundach, a także daje konkretne zalecenia dotyczące ulepszeń. Do ciągłego monitorowania używa się PageSpeed Insights (Google) — zbiera on dane z Chrome User Experience Report (CrUX) od rzeczywistych użytkowników. W aplikacjach natywnych TTI mierzy się przez Android Vitals (Google Play Console) i MetricKit (Apple).

Do monitorowania produkcyjnego popularne są Firebase Performance Monitoring (custom traces), Datadog RUM (Real User Monitoring) i Sentry Performance. Te narzędzia nie tylko pokazują TTI, ale także pozwalają śledzić korelację między TTI a metrykami biznesowymi — konwersją, odpływem, czasem sesji. Zaleca się ustawienie wartości progowych: < 3.8 s — dobrze, 3.8–7 s — wymaga poprawy, > 7 s — krytycznie. Dla aplikacji natywnych progi są ostrzejsze: < 2 s — dobrze, 2–5 s — średnio, > 5 s — krytycznie, ponieważ użytkownicy aplikacji mobilnych są mniej tolerancyjni na opóźnienia.

Konfiguracja Lighthouse CI

Przykład konfiguracji Lighthouse CI do automatycznego sprawdzania TTI w pipeline CI/CD. Po przekroczeniu progu 3.8 sekundy kompilacja jest oznaczana ostrzeżeniem.

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