Time-to-Interactive dans le développement mobile : définition, métrique et mesures

Qu'est-ce que le Time-to-Interactive

Le Time-to-Interactive est une métrique de performance qui capture le moment où une page ou une application est prête pour une interaction complète avec l'utilisateur. Dans le contexte web, le TTI est défini comme le temps écoulé entre le début de la navigation et le moment où trois conditions sont remplies : la page a affiché un contenu utile (First Contentful Paint), le thread principal a été inactif pendant au moins 5 secondes et tous les écouteurs d'événements sont enregistrés. Dans les applications mobiles, le TTI est le temps écoulé entre le lancement de l'Activity et l'initialisation complète de l'UI, lorsque tous les états sont chargés, les animations configurées et que l'utilisateur peut appuyer sur n'importe quel bouton sans délai.

Cette métrique est particulièrement importante pour les applications où la première interaction est critique — écrans de connexion, recherche, paiement. Si le TTI dépasse 5 secondes, l'utilisateur perçoit l'application comme « figée » et peut la fermer. Selon Google (Web Vitals Report, 2025), les pages avec un TTI inférieur à 3,8 secondes génèrent 24% de conversions supplémentaires par rapport aux pages avec un TTI supérieur à 7 secondes. La différence se ressent même à 500 ms — les recherches d'Amazon montrent une perte de revenus de 1% pour chaque 100 ms de retard.

Comment le TTI est calculé

L'algorithme de calcul du TTI est défini dans la spécification W3C et implémenté dans Lighthouse. Le calcul commence par le First Contentful Paint (FCP) — le moment où le navigateur rend le premier pixel de contenu. Ensuite, l'algorithme recherche une « fenêtre de silence » — une période de 5 secondes pendant laquelle aucune tâche sur le thread principal ne dépasse 50 ms. Le TTI est fixé à la dernière tâche avant cette fenêtre. Si aucune fenêtre de silence n'est trouvée dans les 15 secondes, le TTI est défini comme étant égal au temps de la dernière tâche longue. Cet algorithme garantit que le TTI reflète l'état de préparation réel à l'interaction, et non simplement le moment du rendu.

Dans les applications mobiles (Android/iOS), il n'existe pas d'équivalent exact de la spécification W3C, mais le concept est le même. Le TTI peut être mesuré en capturant un horodatage dans onResume (début du lancement) et dans le callback de la première image lorsque toutes les opérations asynchrones sont terminées. Firebase Performance permet de créer un trace personnalisé avec le début et la fin de la session interactive de l'utilisateur. Par exemple, startTrace(“TTI”) dans Application.onCreate et stopTrace() après l'initialisation de tous les SDK et le rendu de la première image.

Exemple de trace personnalisé pour le TTI

Le code Kotlin démontre la mesure du TTI à l'aide de Firebase Performance. Le trace commence dans Application.onCreate et s'arrête après le premier 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 et FID : différences

Dans l'écosystème Core Web Vitals, plusieurs métriques existent, et le TTI est souvent confondu avec le First Contentful Paint (FCP) et le Largest Contentful Paint (LCP). Le FCP est le temps de rendu du premier pixel de contenu, qui ne garantit pas l'interactivité. Le LCP est le temps de rendu du plus grand élément de contenu (image, bloc de texte). Le TTI, quant à lui, ne mesure pas le rendu mais la préparation à l'interaction. La différence est cruciale : le FCP peut être de 1,2 seconde, mais si le thread principal est bloqué par le chargement du bundle JS, le TTI peut atteindre 8 secondes.

Le First Input Delay (FID) mesure le délai entre la première action de l'utilisateur et le moment où le navigateur commence à traiter l'événement. Le FID est la « qualité de l'interactivité », tandis que le TTI est le « temps d'accès à l'interactivité ». Si le TTI indique dans combien de secondes l'interface devient réactive, le FID indique à quel point elle l'était. Un bon TTI est impossible sans un bon FID, car si le thread principal est bloqué, le TTI sera élevé et le FID retardera toute interaction. Dans les applications mobiles, l'équivalent du FID est la Touch Latency — le délai entre le toucher de l'écran et la réponse de l'UI.

TTI dans les applications mobiles

Dans les applications mobiles natives, le concept de TTI n'est pas aussi standardisé que sur le web, mais son importance n'en est pas moindre. Sous Android, le TTI est le temps écoulé entre l'appui sur l'icône de l'application et le moment où l'UI est entièrement interactive : RecyclerView défile, les boutons réagissent aux touches, les animations fonctionnent sans accroc. Pour mesurer le TTI sous Android, on utilise une combinaison de reportFullyDrawn (API 29+) et de FrameMetricsAggregator. reportFullyDrawn est un appel que l'application effectue lorsque le développeur considère que l'UI est prête. Le système capture ce moment et l'inclut dans le rapport Android Vitals.

Sous iOS, les équivalents du TTI sont le Time to First Frame et le Time to Responsive. MetricKit collecte les données de temps de démarrage divisées en phases — chargement de l'exécutable, initialisation des frameworks, rendu de la première image. Apple recommande que le Time to First Frame ne dépasse pas 400 ms et que l'interactivité complète soit atteinte en moins de 2 secondes. Si l'application affiche un écran de placeholder puis charge le contenu, le TTI est calculé non pas à partir de la première image, mais à partir du moment où le contenu réel est prêt à être interactif.

Mesure du TTI sous Android via FrameMetrics

Le code Kotlin suit la première image interactive à l'aide de FrameMetricsAggregator. Le callback est déclenché après la fin de la première image initiée par l'utilisateur.

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éthodes d'optimisation du TTI

L'optimisation du TTI comprend trois directions : la réduction de la charge de travail sur le thread principal, le chargement différé des composants non critiques et le rendu progressif. La première direction consiste à minimiser les opérations synchrones : remplacer SharedPreferences par DataStore, déplacer l'initialisation des SDK vers un thread d'arrière-plan, charger paresseusement les modules Dagger/Hilt. La deuxième est le chargement différé : les écrans qui ne sont pas visibles au démarrage (feuilles inférieures, boîtes de dialogue, onglets) doivent être initialisés après la première image. La troisième est le rendu progressif : d'abord afficher un écran squelette, puis charger le contenu par parties.

Sous Android, une méthode efficace consiste à utiliser la bibliothèque App Startup avec des initialiseurs classés. Par exemple, l'initialiseur Firebase Analytics peut être rendu facultatif et retardé de 2 secondes après le démarrage. Sous iOS, l'équivalent est Initialization Dependencies avec le drapeau lazy. Pour le web, les méthodes clés sont le code splitting, le tree shaking, le preload/preconnect pour les ressources critiques et defer pour le JS non bloquant. Google Lighthouse fournit des recommandations spécifiques : « Eliminate render-blocking resources » et « Defer offscreen images » affectent directement le TTI.

Code splitting dans React Native

Exemple de division du bundle dans React Native à l'aide de React.lazy et Suspense. Le composant HeavyScreen n'est chargé que lorsque l'utilisateur navigue vers cet écran, ce qui réduit le TTI de l'écran initial.

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

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

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

Outils de mesure du TTI

Plusieurs outils sont disponibles pour mesurer le TTI, variant selon la plateforme et la profondeur d'analyse. Sur le web, l'outil principal est Lighthouse dans Chrome DevTools. Lighthouse exécute un audit et affiche le TTI en millisecondes, ainsi que des recommandations spécifiques pour l'amélioration. Pour une surveillance continue, PageSpeed Insights (Google) est utilisé — il collecte les données du Chrome User Experience Report (CrUX) à partir d'utilisateurs réels. Dans les applications natives, le TTI est mesuré via Android Vitals (Google Play Console) et MetricKit (Apple).

Pour la surveillance en production, les outils populaires incluent Firebase Performance Monitoring (traces personnalisés), Datadog RUM (Real User Monitoring) et Sentry Performance. Ces outils ne se contentent pas d'afficher le TTI, ils permettent également de retracer la corrélation entre le TTI et les métriques commerciales — conversion, attrition, durée de session. Seuils recommandés : < 3,8 s — bon, 3,8–7 s — nécessite une amélioration, > 7 s — critique. Pour les applications natives, les seuils sont plus stricts : < 2 s — bon, 2–5 s — moyen, > 5 s — critique, car les utilisateurs d'applications mobiles sont moins tolérants aux retards.

Configuration de Lighthouse CI

Exemple de configuration de Lighthouse CI pour la vérification automatique du TTI dans un pipeline CI/CD. Lorsque le seuil de 3,8 secondes est dépassé, la build est marquée d'un avertissement.

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