Time-to-Interactive nello sviluppo mobile: definizione, metrica e misurazione

Cos'è il Time-to-Interactive

Il Time-to-Interactive è una metrica delle prestazioni che cattura il momento in cui una pagina o un'applicazione è pronta per l'interazione completa con l'utente. Nel contesto web, il TTI è definito come il tempo dall'inizio della navigazione al momento in cui tre condizioni sono soddisfatte: la pagina ha visualizzato contenuto utile (First Contentful Paint), il thread principale è stato inattivo per almeno 5 secondi e tutti i listener di eventi sono registrati. Nelle applicazioni mobili, il TTI è il tempo dall'avvio dell'Activity al completamento dell'inizializzazione dell'UI, quando tutti gli stati sono caricati, le animazioni configurate e l'utente può toccare qualsiasi pulsante senza ritardo.

Questa metrica è particolarmente importante per le applicazioni dove la prima interazione è critica — schermate di login, ricerca, checkout. Se il TTI supera i 5 secondi, l'utente percepisce l'app come “congelata” e potrebbe chiuderla. Secondo Google (Web Vitals Report, 2025), le pagine con TTI inferiore a 3,8 secondi mostrano il 24% in più di conversioni rispetto alle pagine con TTI superiore a 7 secondi. La differenza si avverte già a 500 ms — gli studi di Amazon mostrano una perdita dell'1% del fatturato per ogni 100 ms di ritardo.

Come viene calcolato il TTI

L'algoritmo di calcolo del TTI è definito nella specifica W3C e implementato in Lighthouse. Il calcolo inizia con il First Contentful Paint (FCP) — il momento in cui il browser renderizza il primo pixel di contenuto. L'algoritmo cerca quindi una “finestra di silenzio” — un periodo di 5 secondi durante il quale nessun compito sul thread principale supera i 50 ms. Il TTI viene impostato all'ultimo compito prima di questa finestra. Se non viene trovata alcuna finestra di silenzio entro 15 secondi, il TTI viene impostato uguale al tempo dell'ultimo compito lungo. Questo algoritmo garantisce che il TTI rifletta l'effettiva prontezza all'interazione, non solo il momento del rendering.

Nelle applicazioni mobili (Android/iOS), non esiste un equivalente esatto della specifica W3C, ma il concetto è lo stesso. Il TTI può essere misurato catturando un timestamp in onResume (inizio dell'avvio) e nel callback del primo frame quando tutte le operazioni asincrone sono completate. Firebase Performance consente di creare un trace personalizzato con inizio e fine della sessione interattiva dell'utente. Ad esempio, startTrace(“TTI”) in Application.onCreate e stopTrace() dopo l'inizializzazione di tutti gli SDK e il rendering del primo frame.

Esempio di trace personalizzato per il TTI

Il codice in Kotlin dimostra la misurazione del TTI utilizzando Firebase Performance. Il trace inizia in Application.onCreate e si ferma dopo il primo 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 e FID: differenze

Nell'ecosistema Core Web Vitals esistono diverse metriche e il TTI viene spesso confuso con il First Contentful Paint (FCP) e il Largest Contentful Paint (LCP). Il FCP è il tempo di rendering del primo pixel di contenuto, che non garantisce l'interattività. Il LCP è il tempo di rendering dell'elemento di contenuto più grande (immagine, blocco di testo). Il TTI, invece, non misura il rendering ma la prontezza all'interazione. La differenza è critica: il FCP può essere di 1,2 secondi, ma se il thread principale è bloccato dal caricamento del bundle JS, il TTI può raggiungere gli 8 secondi.

Il First Input Delay (FID) misura il ritardo tra la prima azione dell'utente e il momento in cui il browser inizia a elaborare l'evento. Il FID è la “qualità dell'interattività”, mentre il TTI è il “tempo all'interattività”. Se il TTI mostra dopo quanti secondi l'interfaccia diventa reattiva, il FID mostra quanto è stata reattiva. Un buon TTI è impossibile senza un buon FID, perché se il thread principale è bloccato, il TTI sarà alto e il FID ritarderà qualsiasi interazione. Nelle applicazioni mobili, l'equivalente del FID è la Touch Latency — il ritardo tra il tocco dello schermo e la risposta dell'UI.

TTI nelle applicazioni mobili

Nelle applicazioni mobili native, il concetto di TTI non è standardizzato come sul web, ma la sua importanza non è inferiore. Su Android, il TTI è il tempo dal tocco sull'icona dell'app al momento in cui l'UI è completamente interattiva: RecyclerView scorre, i pulsanti rispondono ai tocchi, le animazioni funzionano senza intoppi. Per misurare il TTI su Android, si utilizza una combinazione di reportFullyDrawn (API 29+) e FrameMetricsAggregator. reportFullyDrawn è una chiamata che l'app effettua quando lo sviluppatore considera l'UI pronta. Il sistema cattura questo momento e lo include nel rapporto Android Vitals.

Su iOS, gli equivalenti del TTI sono Time to First Frame e Time to Responsive. MetricKit raccoglie i dati del tempo di avvio suddivisi in fasi — caricamento dell'eseguibile, inizializzazione dei framework, rendering del primo frame. Apple raccomanda che Time to First Frame non superi i 400 ms e che l'interattività completa sia raggiunta entro 2 secondi. Se l'app mostra una schermata placeholder e poi carica il contenuto, il TTI viene calcolato non dal primo frame ma dal momento in cui il contenuto reale è pronto per l'interazione.

Misurazione del TTI su Android tramite FrameMetrics

Il codice in Kotlin traccia il primo frame interattivo utilizzando FrameMetricsAggregator. Il callback viene attivato al completamento del primo frame avviato dall'utente.

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()
    }
}

Metodi di ottimizzazione del TTI

L'ottimizzazione del TTI comprende tre direzioni: riduzione del carico di lavoro sul thread principale, caricamento differito dei componenti non critici e rendering progressivo. La prima direzione è minimizzare le operazioni sincrone: sostituire SharedPreferences con DataStore, spostare l'inizializzazione degli SDK su un thread in background, caricamento lazy dei moduli Dagger/Hilt. La seconda è il caricamento differito: le schermate non visibili all'avvio (bottom sheet, finestre di dialogo, schede) devono essere inizializzate dopo il primo frame. La terza è il rendering progressivo: prima mostrare una schermata scheletro, poi caricare il contenuto a parti.

Su Android, un metodo efficace è l'utilizzo della libreria App Startup con inizializzatori classificati. Ad esempio, l'inizializzatore di Firebase Analytics può essere reso opzionale e ritardato di 2 secondi dopo l'avvio. Su iOS, l'equivalente è Initialization Dependencies con il flag lazy. Per il web, i metodi chiave sono il code splitting, il tree shaking, il preload/preconnect per le risorse critiche e defer per JS non bloccante. Google Lighthouse fornisce raccomandazioni specifiche: “Eliminate render-blocking resources” e “Defer offscreen images” influenzano direttamente il TTI.

Code Splitting in React Native

Esempio di suddivisione del bundle in React Native utilizzando React.lazy e Suspense. Il componente HeavyScreen viene caricato solo quando l'utente naviga verso quella schermata, riducendo il TTI della schermata iniziale.

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

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

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

Strumenti per misurare il TTI

Diversi strumenti sono disponibili per misurare il TTI, variando per piattaforma e profondità di analisi. Sul web, lo strumento principale è Lighthouse in Chrome DevTools. Lighthouse esegue un audit e restituisce il TTI in millisecondi, oltre a fornire raccomandazioni specifiche per il miglioramento. Per il monitoraggio continuo, si utilizza PageSpeed Insights (Google) — raccoglie i dati dal Chrome User Experience Report (CrUX) da utenti reali. Nelle app native, il TTI viene misurato tramite Android Vitals (Google Play Console) e MetricKit (Apple).

Per il monitoraggio in produzione, gli strumenti popolari includono Firebase Performance Monitoring (trace personalizzati), Datadog RUM (Real User Monitoring) e Sentry Performance. Questi strumenti non solo mostrano il TTI, ma permettono anche di tracciare la correlazione tra il TTI e le metriche aziendali — conversione, abbandono, durata della sessione. Soglie raccomandate: < 3,8 s — buono, 3,8–7 s — necessita miglioramento, > 7 s — critico. Per le app native, le soglie sono più severe: < 2 s — buono, 2–5 s — medio, > 5 s — critico, poiché gli utenti di app mobili sono meno tolleranti ai ritardi.

Configurazione di Lighthouse CI

Esempio di configurazione di Lighthouse CI per la verifica automatica del TTI in una pipeline CI/CD. Quando viene superata la soglia di 3,8 secondi, il build viene contrassegnato con un avviso.

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