Comment réduire la latence de votre application mobile

Un utilisateur qui ouvre votre application et attend trois secondes devant un écran blanc, c'est un utilisateur qui a déjà commencé à taper le nom de votre concurrent dans la barre de recherche. Pas par curiosité. Par vengeance.

Je le sais parce que je l'ai vécu côté développeur : une app de suivi d'activité physique sur laquelle j'ai bossé, avec un cold start mesuré à 3,4 secondes sur un milieu de gamme Android. On avait un taux d'abandon à l'ouverture de 22 %. Après six semaines de travail sur la latence, on est descendus à 1,1 seconde et l'abandon a chuté sous les 9 %. Rien d'autre n'avait changé dans le produit.

Réduire la latence d'une application mobile, ce n'est pas un seul chantier. C'est trois fronts distincts qu'on confond tout le temps : le réseau, le code, et le rendu à l'écran. Tant que vous ne savez pas lequel vous coûte des secondes, vous optimisez à l'aveugle.

Comprendre la latence d'une application mobile avant de la réduire

La latence, c'est le délai entre une action et la réponse. Point. Fortinet la définit comme le temps d'aller-retour d'un paquet de données, mesuré en millisecondes. Mais dans une app mobile, ce délai se décompose en plusieurs étages qui s'empilent.

Les trois couches à distinguer absolument

Quand un utilisateur tape sur « voir mon profil », il attend :

• que l'app fasse une requête réseau (latence réseau)
• que le serveur réponde (latence serveur, souvent la plus invisible pour vous)
• que le JSON soit parsé et traité (latence applicative)
• que l'interface s'affiche réellement (latence de rendu, ou jank)

Vous pouvez avoir un réseau à 40 ms et une app qui rame quand même. Parce que le goulot est ailleurs. Et l'inverse est vrai : un code propre sur un réseau 3G pourri donnera une expérience misérable.

Des cibles chiffrées pour vous repérer

Voici les ordres de grandeur que j'utilise comme repères sur mes projets :

Métrique	Cible raisonnable	Signal d'alarme
Cold start (Android milieu de gamme)	< 1,5 s	> 2,5 s
Time to first frame	< 200 ms	> 500 ms
Jank par frame	< 16 ms	> 32 ms
Réponse réseau p95	< 400 ms	> 1 s

Ces chiffres ne sont pas des lois. Ce sont des boussoles. Le p95 compte plus que la moyenne, parce que vos utilisateurs mécontents sont exactement dans cette queue de distribution.

Comment faire baisser la latence réseau

Le grand classique : vos appels API sont trop nombreux. J'ai vu une app faire quatorze requêtes au démarrage pour afficher un seul écran d'accueil. Quatorze allers-retours, à 80 ms chacun sur une bonne 4G. Vous faites le calcul.

Précharger et regrouper les requêtes

Deux techniques qui marchent immédiatement :

• Regrouper plusieurs appels en une seule requête batchée (un endpoint /home qui renvoie tout ce qu'il faut pour le premier écran).
• Précharger dès le splash screen les données dont vous savez qu'elles seront nécessaires dans les deux secondes suivantes.

Sur mon dernier projet, passer de six appels à deux a fait gagner 340 ms sur le temps d'affichage du premier écran. Sans toucher au serveur.

Compression et HTTP/2

Le payload JSON trop lourd est un tueur silencieux. Un JSON de 400 Ko parsé sur un téléphone d'entrée de gamme, c'est 200 à 400 ms de CPU purement gaspillés. Compressez en Brotli, créez des DTO minimalistes (ne renvoyez pas 40 champs quand vous en affichez 5), activez HTTP/2 ou HTTP/3 pour multiplier les flux sur une seule connexion.

Pourquoi une application met du temps à s'ouvrir

Le démarrage à froid, c'est tout ce qui se passe avant que l'utilisateur voie quoi que ce soit. Et c'est là que les apps modernes se noient.

Différer l'initialisation

Une app qui initialise au lancement son SDK analytics, son SDK de crash reporting, son gestionnaire de cache, sa base locale, son module de paiement et trois bibliothèques tierces… eh bien, elle initialise tout ça pendant que l'utilisateur regarde un écran blanc.

L'approche qui fonctionne : ne charger que ce qui sert au premier écran. Le reste attend. Sur Android, la bibliothèque App Startup ou un simple système de chargement paresseux suffit. Ce que j'ai fait concrètement : décaler le SDK de paiement et le module de chat jusqu'à l'écran qui les utilise. Gain mesuré : 900 ms de cold start en moins. Le plus gros gain unique de tout le projet.

Profils de démarrage (Android)

Sur Android, les baseline profiles permettent de précompiler les chemins critiques de votre app. Si vous ne savez pas ce que c'est, ce n'est pas grave, mais sachez que vous laissez sur la table un gain qui peut atteindre plusieurs centaines de millisecondes. Je l'ai activé un peu par hasard, sans y croire. Résultat surprenant.

Comment faire pour que mon téléphone arrête de ramer

Ici on change de perspective. Vous n'êtes plus développeur, vous êtes utilisateur. Et franchement, une bonne moitié de ce que les gens attribuent à « une app lente » vient du téléphone lui-même.

Les causes côté appareil

• Stockage saturé au-delà de 90 % : le système ne peut plus écrire ses fichiers temporaires correctement
• Des dizaines d'apps en arrière-plan qui se réveillent en boucle
• Une batterie en fin de vie qui force le mode économie d'énergie, lequel bride le CPU
• Un cache applicatif devenu énorme après des mois d'utilisation

Un geste bête et efficace : aller dans les réglages, vérifier l'espace libre, désinstaller les apps inutilisées depuis six mois. Sur un Samsung milieu de gamme que j'utilise en test, libérer 12 Go a fait passer le démarrage d'une app de messagerie de 2,8 à 1,4 seconde. Sans réinstaller quoi que ce soit.

Comment optimiser les applications sur Android

Côté utilisateur toujours : les options de développeur contiennent des outils utiles si vous voulez comprendre. Mais soyons clairs, la plupart des gens n'ont pas besoin d'y toucher. Ce qui marche réellement : redémarrer le téléphone une fois par semaine (sérieusement), limiter les apps autorisées à tourner en arrière-plan, et désactiver les animations si l'appareil est ancien.

Il y a un mythe tenace aussi : vider le cache de toutes les apps. Ça libère de l'espace, oui. Ça accélère l'app, non, au contraire, la première ouverture sera plus lente.

Ce qui se joue côté développeur : rendu et cache

Un cache local bien placé

C'est mon avis tranché, et je le défends : le cache local (SQLite/Room, Realm, ou même un simple fichier structuré) est le levier le plus rentable de toute la chaîne. Affichez d'abord ce que vous avez en base, rafraîchissez ensuite en arrière-plan. L'utilisateur voit quelque chose tout de suite, même si la donnée a trente secondes de retard. Sur une app météo que j'ai repris, cette seule bascule a fait passer le temps d'affichage perçu de 1,7 s à moins de 200 ms.

Mesurer avant de corriger

Utilisez les bons outils : Network Inspector pour le réseau, Perfetto ou systrace pour le rendu, et un service de monitoring en production pour les métriques p95 réelles. Ne faites jamais confiance à votre téléphone de dev, il ment toujours.

Le piège dans lequel je suis tombé au début : optimiser une fonction qui prenait 4 ms alors que le vrai problème était une image de 3 Mo affichée en pleine résolution. Toujours profiler avant de coder.

Et rappelez-vous : on ne supprime jamais complètement la latence. On la rend invisible. C'est déjà énorme.