Time-to-Interactive v mobilním vývoji: co to je, metrika a měření

Co je Time-to-Interactive

Time-to-Interactive je metrika výkonu, která zaznamenává okamžik, kdy je stránka nebo aplikace připravena k plné interakci s uživatelem. V kontextu webu je TTI definováno jako čas od začátku navigace do okamžiku, kdy jsou splněny tři podmínky: stránka zobrazila užitečný obsah (First Contentful Paint), hlavní vlákno bylo volné alespoň 5 sekund a všechny posluchače událostí byly zaregistrovány. V mobilních aplikacích je TTI čas od spuštění Activity do úplné inicializace UI, kdy jsou načteny všechny stavy, nastaveny animace a uživatel může kliknout na libovolné tlačítko bez zpoždění.

Tato metrika je obzvláště důležitá pro aplikace, kde je první interakce kritická — přihlašovací obrazovky, vyhledávání, zadávání objednávky. Pokud TTI přesáhne 5 sekund, uživatel vnímá aplikaci jako “zmrzlou” a může ji zavřít. Podle údajů Google (Web Vitals Report, 2025) vykazují stránky s TTI kratším než 3,8 sekundy o 24% více konverzí než stránky s TTI delším než 7 sekund. Rozdíl je patrný i při 500 ms — výzkumy Amazonu ukazují ztrátu 1% příjmů za každých 100 ms zpoždění.

Jak se vypočítává TTI

Algoritmus výpočtu TTI je definován ve specifikaci W3C a implementován v nástroji Lighthouse. Výpočet začíná s First Contentful Paint (FCP) — okamžikem, kdy prohlížeč vykreslil první pixel obsahu. Poté algoritmus hledá “okno ticha” — časový interval 5 sekund, během kterého nebyly na hlavním vlákně žádné úlohy delší než 50 ms. TTI je zaznamenáno u poslední úlohy před tímto oknem. Pokud není okno ticha nalezeno do 15 sekund, TTI se považuje za rovné času poslední dlouhé úlohy. Tento algoritmus zaručuje, že TTI odráží skutečnou připravenost k interakci, nejen okamžik vykreslení.

V mobilních aplikacích (Android/iOS) neexistuje přesný ekvivalent specifikace W3C, ale koncept je stejný. TTI lze měřit zaznamenáním časového razítka v onResume (začátek spouštění) a v callbacku prvního snímku, když jsou všechny asynchronní operace dokončeny. Knihovna Firebase Performance umožňuje definovat vlastní trace se začátkem a koncem interaktivní relace uživatele. Například startTrace(”tti”) v Application.onCreate a stopTrace() po dokončení inicializace všech SDK a vykreslení prvního snímku.

Příklad vlastní trace pro TTI

Kód v Kotlinu demonstruje měření TTI pomocí Firebase Performance. Trace začíná v Application.onCreate a zastavuje se po prvním 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 a FID: rozdíly

V ekosystému Core Web Vitals existuje několik metrik a TTI je často zaměňováno s First Contentful Paint (FCP) a Largest Contentful Paint (LCP). FCP je čas vykreslení prvního pixelu obsahu, který nezaručuje interaktivitu. LCP je čas vykreslení největšího prvku obsahu (obrázku, textového bloku). TTI ale neměří vykreslení, nýbrž připravenost k interakci. Rozdíl je kritický: FCP může být 1,2 sekundy, ale pokud je hlavní vlákno blokováno načítáním JS balíčku, TTI může dosáhnout 8 sekund.

First Input Delay (FID) měří zpoždění mezi první akcí uživatele a okamžikem, kdy prohlížeč začal zpracovávat událost. FID je “kvalita interaktivity”, zatímco TTI je “doba do interaktivity”. Pokud TTI ukazuje, po kolika sekundách se rozhraní stalo responzivním, FID ukazuje, jak responzivní bylo. Dobré TTI bez dobrého FID je nemožné, protože pokud je hlavní vlákno blokováno, TTI bude vysoké a FID — jakákoli interakce bude zpožděna. V mobilních aplikacích je ekvivalentem FID Touch Latency — zpoždění mezi dotykem obrazovky a reakcí UI.

TTI v mobilních aplikacích

V nativních mobilních aplikacích není koncept TTI tak standardizovaný jako na webu, ale jeho důležitost není menší. V Androidu je TTI čas od kliknutí na ikonu aplikace do okamžiku, kdy je UI plně interaktivní: RecyclerView se posouvá, tlačítka reagují na dotyky, animace fungují bez trhání. Pro měření TTI v Androidu se používá kombinace reportFullyDrawn (API 29+) a FrameMetricsAggregator. reportFullyDrawn je volání, které aplikace provádí v okamžiku, kdy vývojář považuje UI za připravené. Systém tento okamžik zaznamená a zahrne jej do zprávy Android Vitals.

V iOS je ekvivalentem TTI metrika Time to First Frame a Time to Responsive. MetricKit shromažďuje údaje o době spouštění rozdělené do fází — načítání spustitelného souboru, inicializace frameworků, vykreslení prvního snímku. Apple doporučuje, aby Time to First Frame nepřesáhlo 400 ms a plné interaktivity bylo dosaženo do 2 sekund. Pokud aplikace zobrazí placeholder obrazovku a poté načte obsah, TTI se počítá nikoli podle prvního snímku, ale podle okamžiku, kdy je skutečný obsah připraven k interakci.

Měření TTI v Androidu pomocí FrameMetrics

Kód v Kotlinu sleduje první interaktivní snímek pomocí FrameMetricsAggregator. Callback se aktivuje po dokončení prvního snímku iniciovaného uživatelem.

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", "Doba do interaktivity: $ttiMs ms")
        metrics.reset()
    }
}

Metody optimalizace TTI

Optimalizace TTI zahrnuje tři směry: snížení objemu práce na hlavním vlákně, odložené načítání nekritických komponent a progresivní vykreslování. První směr — minimalizace synchronních operací: nahrazení SharedPreferences pomocí DataStore, přesun inicializace SDK na vlákno na pozadí, líné načítání modulů Dagger/Hilt. Druhý — odložené načítání: obrazovky, které nejsou při spuštění viditelné (bottom sheets, dialogy, karty), by měly být inicializovány po prvním snímku. Třetí — progresivní vykreslování: nejprve se zobrazí kosterní obrazovka, poté se obsah načítá po částech.

V Androidu je účinnou metodou použití knihovny App Startup s řazením inicializátorů. Například inicializátor Firebase Analytics lze učinit volitelným a jeho provedení odložit o 2 sekundy po spuštění. V iOS je ekvivalentem Initialization Dependencies s příznakem lazy. Pro web jsou klíčovými metodami code splitting (rozdělení balíčku), tree shaking (odstranění mrtvého kódu), preload/preconnect pro kritické zdroje a defer pro neblokující JS. Google Lighthouse dává konkrétní doporučení: “Eliminate render-blocking resources” a “Defer offscreen images” přímo ovlivňují TTI.

Code splitting v React Native

Příklad rozdělení balíčku v React Native pomocí React.lazy a Suspense. Komponenta HeavyScreen se načítá pouze tehdy, když uživatel přejde na tuto obrazovku, čímž se snižuje TTI úvodní obrazovky.

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

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

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

Nástroje pro měření TTI

Pro měření TTI existuje několik nástrojů lišících se platformou a hloubkou analýzy. Na webu je hlavním nástrojem Lighthouse v Chrome DevTools. Lighthouse spouští audit a zobrazuje TTI v milisekundách a také poskytuje konkrétní doporučení pro zlepšení. Pro kontinuální monitorování se používá PageSpeed Insights (Google) — shromažďuje data z Chrome User Experience Report (CrUX) od skutečných uživatelů. V nativních aplikacích se TTI měří pomocí Android Vitals (Google Play Console) a MetricKit (Apple).

Pro monitorování v produkci jsou populární Firebase Performance Monitoring (custom traces), Datadog RUM (Real User Monitoring) a Sentry Performance. Tyto nástroje nejen zobrazují TTI, ale také umožňují sledovat korelaci mezi TTI a obchodními metrikami — konverzí, odchodovostí, délkou relace. Doporučuje se nastavit prahové hodnoty: < 3,8 s — dobře, 3,8–7 s — vyžaduje zlepšení, > 7 s — kriticky. Pro nativní aplikace jsou prahy přísnější: < 2 s — dobře, 2–5 s — průměrně, > 5 s — kriticky, protože uživatelé mobilních aplikací jsou méně tolerantní ke zpožděním.

Konfigurace Lighthouse CI

Příklad konfigurace Lighthouse CI pro automatickou kontrolu TTI v pipeline CI/CD. Při překročení prahu 3,8 sekundy je sestavení označeno varováním.

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