Cold start (temps de démarrage)

La mesure vient avant toute optimisation, en build release uniquement. Sur Android, adb shell am start -W et la ligne Displayed de logcat donnent le TTID ; reportFullyDrawn (appelable depuis un module natif au moment où l’écran est prêt) donne le TTFD. Sur iOS, le template App Launch d’Instruments découpe le pre-main (chargement des frameworks dynamiques, initialiseurs statiques) et le post-main. Côté JavaScript, performance.mark et le panneau Performance de React Native DevTools montrent le temps entre l’exécution du bundle et le premier commit React. Un vrai device d’entrée de gamme Android est la référence, pas le simulateur.

Les causes habituelles, dans l’ordre où je les trouve : du travail au niveau module (initialisation de SDK, lecture de stockage, gros require d’images) exécuté avant le premier rendu ; un bundle qui charge tous les écrans alors que require inline ou le lazy loading des routes permet de différer ; une cascade de requêtes réseau bloquantes derrière le splash ; des polyfills Intl lourds ; et sur iOS un use_frameworks! dynamique qui multiplie les frameworks à charger au pre-main. Hermes et son bytecode règlent la partie parsing, pas ces cinq points.

Ce que je regarde en premier dans un projet : ce qui s’exécute entre index.js et le premier écran, le nombre de providers imbriqués à la racine, et si le splash est masqué sur un événement précis (données prêtes) plutôt qu’un timer.