Time-to-Interactive en desarrollo móvil: qué es, métrica y mediciones

Qué es Time-to-Interactive

Time-to-Interactive es una métrica de rendimiento que captura el momento en que una página o aplicación está lista para la interacción completa con el usuario. En el contexto web, el TTI se define como el tiempo desde el inicio de la navegación hasta que se cumplen tres condiciones: la página ha mostrado contenido útil (First Contentful Paint), el hilo principal ha estado inactivo durante al menos 5 segundos y todos los listeners de eventos están registrados. En aplicaciones móviles, el TTI es el tiempo desde el inicio de la Activity hasta la inicialización completa de la UI, cuando todos los estados están cargados, las animaciones configuradas y el usuario puede tocar cualquier botón sin demora.

Esta métrica es especialmente importante para aplicaciones donde la primera interacción es crítica — pantallas de inicio de sesión, búsqueda, proceso de pago. Si el TTI supera los 5 segundos, el usuario percibe la aplicación como “congelada” y puede cerrarla. Según Google (Web Vitals Report, 2025), las páginas con TTI inferior a 3.8 segundos muestran un 24% más de conversiones que las páginas con TTI superior a 7 segundos. La diferencia se nota incluso en 500 ms — los estudios de Amazon muestran una pérdida del 1% de ingresos por cada 100 ms de retraso.

Cómo se calcula el TTI

El algoritmo de cálculo del TTI está definido en la especificación W3C e implementado en Lighthouse. El cálculo comienza con First Contentful Paint (FCP) — el momento en que el navegador renderiza el primer píxel de contenido. Luego, el algoritmo busca una “ventana de silencio” — un período de 5 segundos durante el cual ninguna tarea en el hilo principal supera los 50 ms. El TTI se establece en la última tarea antes de esta ventana. Si no se encuentra ninguna ventana de silencio en 15 segundos, el TTI se iguala al tiempo de la última tarea larga. Este algoritmo garantiza que el TTI refleje la preparación real para la interacción, no solo el momento del renderizado.

En aplicaciones móviles (Android/iOS), no existe un equivalente exacto de la especificación W3C, pero el concepto es el mismo. El TTI se puede medir capturando una marca de tiempo en onResume (inicio de la aplicación) y en el callback del primer frame cuando todas las operaciones asincrónicas se hayan completado. Firebase Performance permite crear un trace personalizado con inicio y fin de la sesión interactiva del usuario. Por ejemplo, startTrace(“TTI”) en Application.onCreate y stopTrace() después de que todos los SDK se hayan inicializado y se haya renderizado el primer frame.

Ejemplo de trace personalizado para TTI

El código en Kotlin demuestra la medición del TTI mediante Firebase Performance. El trace comienza en Application.onCreate y se detiene después del primer 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 y FID: diferencias

En el ecosistema de Core Web Vitals existen varias métricas, y TTI a menudo se confunde con First Contentful Paint (FCP) y Largest Contentful Paint (LCP). FCP es el tiempo de renderizado del primer píxel de contenido, que no garantiza interactividad. LCP es el tiempo de renderizado del elemento de contenido más grande (imagen, bloque de texto). TTI, sin embargo, no mide el renderizado sino la preparación para la interacción. La diferencia es crítica: FCP puede ser de 1.2 segundos, pero si el hilo principal está bloqueado por la carga del bundle JS, el TTI puede alcanzar los 8 segundos.

First Input Delay (FID) mide el retraso entre la primera acción del usuario y el momento en que el navegador comienza a procesar el evento. FID es la “calidad de la interactividad”, mientras que TTI es el “tiempo hasta la interactividad”. Si TTI muestra cuántos segundos faltan para que la interfaz responda, FID muestra qué tan receptiva fue. Un buen TTI es imposible sin un buen FID, porque si el hilo principal está bloqueado, el TTI será alto y el FID retrasará cualquier interacción. En aplicaciones móviles, el equivalente de FID es Touch Latency — el retraso entre tocar la pantalla y la respuesta de la UI.

TTI en aplicaciones móviles

En las aplicaciones móviles nativas, el concepto de TTI no está tan estandarizado como en la web, pero su importancia no es menor. En Android, el TTI es el tiempo desde que se toca el icono de la aplicación hasta que la UI es completamente interactiva: RecyclerView se desplaza, los botones responden a los toques, las animaciones funcionan sin problemas. Para medir el TTI en Android se utiliza una combinación de reportFullyDrawn (API 29+) y FrameMetricsAggregator. reportFullyDrawn es una llamada que la aplicación realiza cuando el desarrollador considera que la UI está lista. El sistema captura este momento y lo incluye en el informe de Android Vitals.

En iOS, los equivalentes del TTI son Time to First Frame y Time to Responsive. MetricKit recopila datos de tiempo de inicio divididos en fases — carga del ejecutable, inicialización de frameworks, renderizado del primer frame. Apple recomienda que Time to First Frame no supere los 400 ms, y que la interactividad completa se alcance en 2 segundos. Si la aplicación muestra una pantalla placeholder y luego carga contenido, el TTI se calcula no desde el primer frame sino desde el momento en que el contenido real está listo para la interacción.

Medición del TTI en Android mediante FrameMetrics

El código en Kotlin rastrea el primer frame interactivo usando FrameMetricsAggregator. El callback se activa después de que se completa el primer frame iniciado por el usuario.

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

Métodos de optimización del TTI

La optimización del TTI incluye tres direcciones: reducción de la carga en el hilo principal, carga diferida de componentes no críticos y renderizado progresivo. La primera dirección es minimizar las operaciones síncronas: reemplazar SharedPreferences por DataStore, mover la inicialización de SDK a un hilo de fondo, carga perezosa de módulos Dagger/Hilt. La segunda es la carga diferida: las pantallas que no son visibles al inicio (bottom sheets, diálogos, pestañas) deben inicializarse después del primer frame. La tercera es el renderizado progresivo: primero mostrar un skeleton screen, luego cargar el contenido por partes.

En Android, un método efectivo es el uso de la librería App Startup con inicializadores clasificados. Por ejemplo, el inicializador de Firebase Analytics puede hacerse opcional y retrasarse 2 segundos después del inicio. En iOS, el equivalente son Initialization Dependencies con la bandera lazy. Para la web, los métodos clave son code splitting, tree shaking, preload/preconnect para recursos críticos y defer para JS no bloqueante. Google Lighthouse ofrece recomendaciones específicas: “Eliminate render-blocking resources” y “Defer offscreen images” afectan directamente al TTI.

Code Splitting en React Native

Ejemplo de división del bundle en React Native usando React.lazy y Suspense. El componente HeavyScreen se carga solo cuando el usuario navega a esa pantalla, reduciendo el TTI de la pantalla inicial.

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

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

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

Herramientas para medir el TTI

Existen varias herramientas para medir el TTI, que varían según la plataforma y la profundidad del análisis. En la web, la herramienta principal es Lighthouse en Chrome DevTools. Lighthouse ejecuta una auditoría y muestra el TTI en milisegundos, además de ofrecer recomendaciones específicas para mejorar. Para monitoreo continuo se utiliza PageSpeed Insights (Google) — recopila datos del Chrome User Experience Report (CrUX) de usuarios reales. En aplicaciones nativas, el TTI se mide a través de Android Vitals (Google Play Console) y MetricKit (Apple).

Para monitoreo en producción, las herramientas populares incluyen Firebase Performance Monitoring (traces personalizados), Datadog RUM (Real User Monitoring) y Sentry Performance. Estas herramientas no solo muestran el TTI, sino que también permiten rastrear la correlación entre el TTI y las métricas de negocio — conversión, abandono, tiempo de sesión. Umbrales recomendados: < 3.8 s — bueno, 3.8–7 s — necesita mejora, > 7 s — crítico. Para aplicaciones nativas, los umbrales son más estrictos: < 2 s — bueno, 2–5 s — promedio, > 5 s — crítico, ya que los usuarios de aplicaciones móviles son menos tolerantes a los retrasos.

Configuración de Lighthouse CI

Ejemplo de configuración de Lighthouse CI para verificación automatizada del TTI en un pipeline CI/CD. Si se supera el umbral de 3.8 segundos, el build se marca con una advertencia.

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