Time-to-Interactive a mobilfejlesztésben: mi ez, metrika és mérések

Mi az a Time-to-Interactive

Time-to-Interactive egy teljesítménymetrika, amely rögzíti azt a pillanatot, amikor az oldal vagy alkalmazás készen áll a teljes körű interakcióra a felhasználóval. Webes kontextusban a TTI a navigáció kezdetétől addig a pillanatig eltelt időként van meghatározva, amikor három feltétel teljesül: az oldal hasznos tartalmat jelenített meg (First Contentful Paint), a fő szál legalább 5 másodpercig szabad volt, és az összes eseményfigyelő regisztrálásra került. Mobil alkalmazásokban a TTI az Activity elindításától az UI teljes inicializálásáig eltelt idő, amikor az összes állapot betöltődött, az animációk be lettek állítva, és a felhasználó késedelem nélkül bármelyik gombra kattinthat.

A metrika különösen fontos azoknál az alkalmazásoknál, ahol az első interakció kritikus — bejelentkezési képernyők, keresés, rendelés leadása. Ha a TTI meghaladja az 5 másodpercet, a felhasználó “lefagyottnak” érzékeli az alkalmazást, és bezárhatja. A Google adatai szerint (Web Vitals Report, 2025) a 3,8 másodpercnél kisebb TTI-vel rendelkező oldalak 24%-kal több konverziót mutatnak, mint a 7 másodpercnél nagyobb TTI-vel rendelkező oldalak. A különbség már 500 ms-nál is érezhető — az Amazon kutatásai szerint minden 100 ms késés 1% bevételkiesést okoz.

Hogyan számítják ki a TTI-t

A TTI kiszámításának algoritmusa a W3C specifikációban van meghatározva és a Lighthouse eszközben van implementálva. A számítás a First Contentful Paint (FCP) értékkel kezdődik — azzal a pillanattal, amikor a böngésző megjelenítette a tartalom első képpontját. Ezután az algoritmus egy “csendablakot” keres — egy 5 másodperces időintervallumot, amelyben nem voltak 50 ms-nál hosszabb feladatok a fő szálon. A TTI az ablak előtti utolsó feladatnál kerül rögzítésre. Ha a csendablak 15 másodpercen belül nem található meg, a TTI megegyezik az utolsó hosszú feladat idejével. Ez az algoritmus garantálja, hogy a TTI a valós interakciós készséget tükrözi, nem csupán a renderelés pillanatát.

Mobil alkalmazásokban (Android/iOS) nincs pontos megfelelője a W3C specifikációnak, de a koncepció ugyanaz. A TTI mérhető egy időbélyeg rögzítésével az onResume-ban (indítás kezdete) és az első képkocka callback-jében, amikor az összes aszinkron művelet befejeződött. A Firebase Performance könyvtár lehetővé teszi egyéni trace meghatározását a felhasználói interaktív munkamenet kezdetével és végével. Például startTrace(”tti”) az Application.onCreate-ben és stopTrace() az összes SDK inicializálásának és az első képkocka megjelenítésének befejezése után.

Példa egyéni trace-re a TTI-hez

A Kotlin kód a TTI mérését mutatja be a Firebase Performance segítségével. A trace az Application.onCreate-ben kezdődik és az első reportFullyDrawn után áll le.

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 és FID: különbségek

A Core Web Vitals ökoszisztémában több metrika létezik, és a TTI-t gyakran összekeverik a First Contentful Paint (FCP) és a Largest Contentful Paint (LCP) metrikákkal. Az FCP a tartalom első képpontjának megjelenítési ideje, ami nem garantálja az interaktivitást. Az LCP a tartalom legnagyobb elemének (kép, szövegblokk) megjelenítési ideje. A TTI azonban nem a renderelést, hanem az interakciós készséget méri. A különbség kritikus: az FCP lehet 1,2 másodperc, de ha a fő szálat blokkolja a JS-csomag betöltése, a TTI elérheti a 8 másodpercet.

First Input Delay (FID) a felhasználó első művelete és a böngésző eseményfeldolgozásának kezdete közötti késlekedést méri. Az FID az “interaktivitás minősége”, míg a TTI az “interaktivitásig eltelt idő”. Ha a TTI megmutatja, hány másodperc után lett a felület reszponzív, az FID megmutatja, mennyire volt reszponzív. Jó TTI jó FID nélkül lehetetlen, mert ha a fő szál blokkolva van, a TTI magas lesz, és az FID — minden interakció késlekedni fog. Mobil alkalmazásokban az FID megfelelője a Touch Latency — a képernyő érintése és az UI reakciója közötti késés.

TTI mobil alkalmazásokban

A natív mobil alkalmazásokban a TTI koncepciója nincs annyira szabványosítva, mint a weben, de fontossága nem kisebb. Androidban a TTI az alkalmazás ikonjára való kattintástól addig a pillanatig eltelt idő, amikor az UI teljesen interaktív: a RecyclerView görgethető, a gombok reagálnak az érintésre, az animációk akadozás nélkül működnek. A TTI méréséhez Androidban a reportFullyDrawn (API 29+) és a FrameMetricsAggregator kombinációját használják. A reportFullyDrawn egy hívás, amelyet az alkalmazás abban a pillanatban tesz, amikor a fejlesztő az UI-t késznek tekinti. A rendszer rögzíti ezt a pillanatot, és belefoglalja az Android Vitals jelentésbe.

iOS-ben a TTI megfelelője a Time to First Frame és a Time to Responsive metrika. A MetricKit az indítási idő adatait fázisokra bontva gyűjti — a végrehajtható fájl betöltése, a keretrendszerek inicializálása, az első képkocka megjelenítése. Az Apple azt javasolja, hogy a Time to First Frame ne haladja meg a 400 ms-ot, és a teljes interaktivitás 2 másodpercen belül érhető el. Ha az alkalmazás egy helyőrző képernyőt jelenít meg, majd betölti a tartalmat, a TTI nem az első képkocka, hanem a tényleges tartalom interakcióra való készenlétének pillanata alapján kerül kiszámításra.

TTI mérése Androidban a FrameMetrics segítségével

A Kotlin kód az első interaktív képkockát követi nyomon a FrameMetricsAggregator segítségével. A callback a felhasználó által kezdeményezett első képkocka befejezése után aktiválódik.

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", "Interaktivitásig eltelt idő: $ttiMs ms")
        metrics.reset()
    }
}

TTI optimalizálási módszerek

A TTI optimalizálása három irányt foglal magában: a fő szál munkaterhének csökkentése, a nem kritikus komponensek késleltetett betöltése és a progresszív renderelés. Az első irány — a szinkron műveletek minimalizálása: a SharedPreferences cseréje DataStore-ra, az SDK inicializálásának áthelyezése háttérszálba, a Dagger/Hilt modulok lusta betöltése. A második — késleltetett betöltés: az induláskor nem látható képernyők (bottom sheets, párbeszédpanelek, lapok) inicializálását az első képkocka után kell elvégezni. A harmadik — progresszív renderelés: először egy vázképernyő jelenik meg, majd a tartalom fokozatosan töltődik be.

Androidban egy hatékony módszer az App Startup könyvtár használata az inicializálók rangsorolásával. Például a Firebase Analytics inicializálója opcionálissá tehető, és végrehajtása 2 másodperccel késleltethető az indulás után. iOS-ben ennek megfelelője az Initialization Dependencies a lazy jelzővel. A weben a kulcsfontosságú módszerek a code splitting (a csomag felosztása), a tree shaking (holt kód eltávolítása), a preload/preconnect a kritikus erőforrásokhoz és a defer a nem blokkoló JS-hez. A Google Lighthouse konkrét ajánlásokat ad: a “Eliminate render-blocking resources” és a “Defer offscreen images” közvetlenül befolyásolja a TTI-t.

Code splitting a React Native-ben

Példa a csomag felosztására a React Native-ben a React.lazy és a Suspense segítségével. A HeavyScreen komponens csak akkor töltődik be, amikor a felhasználó erre a képernyőre navigál, csökkentve a kezdőképernyő TTI-jét.

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

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

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

Eszközök a TTI mérésére

A TTI mérésére több eszköz létezik, amelyek platform és elemzési mélység szerint különböznek. A weben a fő eszköz a Lighthouse a Chrome DevTools-ban. A Lighthouse auditot futtat, és ezredmásodpercben jeleníti meg a TTI-t, valamint konkrét javaslatokat ad a fejlesztéshez. A folyamatos monitorozáshoz a PageSpeed Insights (Google) használatos — valós felhasználóktól gyűjt adatokat a Chrome User Experience Report (CrUX) segítségével. Natív alkalmazásokban a TTI-t az Android Vitals (Google Play Console) és a MetricKit (Apple) méri.

Éles monitorozáshoz a Firebase Performance Monitoring (custom traces), a Datadog RUM (Real User Monitoring) és a Sentry Performance népszerű. Ezek az eszközök nemcsak a TTI-t mutatják, hanem lehetővé teszik a TTI és az üzleti mutatók — konverzió, lemorzsolódás, munkamenet időtartama — közötti korreláció nyomon követését is. Javasolt küszöbértékek beállítása: < 3,8 mp — jó, 3,8–7 mp — fejlesztést igényel, > 7 mp — kritikus. Natív alkalmazások esetén a küszöbök szigorúbbak: < 2 mp — jó, 2–5 mp — közepes, > 5 mp — kritikus, mivel a mobilalkalmazás-felhasználók kevésbé toleránsak a késésekkel szemben.

Lighthouse CI konfiguráció

Példa a Lighthouse CI konfigurációjára a TTI automatikus ellenőrzéséhez a CI/CD pipeline-ban. A 3,8 másodperces küszöb túllépése esetén a build figyelmeztetéssel kerül megjelölésre.

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