Devoxx 2015 – La latence applicative mobile et le cerveau

Dans un quickie (format de 15 minutes) particulièrement riche en informations, Nicolas Babel (@nicbaboul) et Allan Denis sont revenus sur la latence applicative mobile, sa provenance et comment essayer de la réduire.

Pour bien comprendre le principe de la latence, voici la définition qui nous a été donnée:

Délai entre l’action d’un utilisateur et les conséquences de cette action

Comment fonctionne le cerveau ?

Afin de comprendre les réactions des utilisateurs, leur démarche a été la suivante: comprendre le fonctionnement du cerveau pour en déduire la latence acceptable pour un utilisateur. En effet le cerveau est un outil très efficace et a été « conçu » pour répondre rapidement.

Ainsi, lorsque qu’une personne pose une question fermée (réponse par oui ou par non) à une autre personne, cette dernière répond en 100 ms. Pour une question ouverte, le délai passe à 500 ms.

Il faut en déduire que si une IHM répond en moins de 500ms, elle fait appel à la partie émotionnelle du cerveau. Entre 500ms et 1 seconde, le délai est acceptable.

Au-delà de 2 secondes, le temps d’attente est très long. Le cerveau va physiquement peiner à attendre, ce qui entrainera la fatigue ou l’énervement de l’utilisateur et donc une perte de client.

Une fois ce comportement compris, il faut étudier d’où vient cette latence dans une application mobile. Le paramètre le plus important est la latence réseau.

La latence réseau

En effet sur un réseau filaire classique (ADSL), la latence réseau est de 40 ms. C’est à dire qu’il faut 40 ms à un PC pour établir une connexion avec le serveur d’un site web.

Sur les réseaux mobiles, ce délai passe à plus de 200 ms pour de la 4G et même 300 ms pour de la 3G et ceci pour une seule requête.

C’est à dire que pour deux requêtes HTTP distinctes sur un site web, il y a un minimum de 600 ms de latence réseau, ce qui est déjà au delà du temps émotionnel du cerveau (pour rappel à 500 ms).

Des études des grands du web (Google, Ebay, Netflix) ont montré qu’au delà du temps acceptable pour le cerveau, 100 ms de latence en plus provoquent une diminution de 1% des revenus et 5% de pages vues en moins.

Pour Google qui a eu un chiffre d’affaire de plus 43 milliards de dollars en 2013, 1% de revenu en moins représente un manque à gagner considérable. Ces sociétés ont donc cherché des solutions pour réduire au maximum cette latence réseau.

Solutions possibles

Ces éditeurs ont donc développé ou utilisé deux techniques: changer le mode de communication et réduire la quantité de données qui transite sur le réseau.

D’un point de vue connexion, ils proposent de passer par un protocole full duplex ou des APIs en mode push comme les protocole SPDY, MQTT ou encore les websockets.

Ces techniques se connectent une seule fois au serveur et font transiter toutes leurs données via cette seule connexion. Ainsi la latence réseau n’est subie qu’une seule fois.

Dans un deuxième temps, afin de réduire la quantité de données, il existe le format JSON Patch. Ce format consiste à ne renvoyer que les mises à jour nécessaires à l’IHM d’un JSON précédemment fourni.

Netflix en a profité pour pousser le concept plus loin avec son propre format: le JsonG.

Il s’agit de pousser la mise à jour du JSON Patch directement dans le cache de l’application. L’IHM va ensuite se mettre à jour en s’appuyant sur le cache et donc sans contrainte réseau.

L’IHM des films disponibles dans Netflix a été bâtie sur ce principe.

Voilà pour ce quickie fort intéressant sur les problématiques de latence. Bien entendu, ces solutions peuvent s’appliquer sur une application desktop classique même si celle-ci souffre moins des latences réseaux.

Vous pouvez retrouver la présentation des speakers sur slideshare.