Quelle cible de performance ?

Il faut surveiller les performances, mais quelles limites se poser ? Quelle cible doit avoir votre application pour être considérée statisfaisante ?

L’année dernière je reprenais ici même les chiffres de Jackob Nielsen, lui même les reprenant d’autres études qui remontent jusqu’en 68. On ne parle pas en effet que de site web. Puisque ces paliers sont liés à l’humain, ils sont similaires quel que soit le type d’interface.

On m’a posé récemment la question des cibles de réactivité à avoir pour un site web. Dans le même temps j’ai vu que Ben Galbraith et Dion Almaer, les fondateurs d’Ajaxian, reprennent eux aussi Jackob dans « Even Faster Web Sites ».

Aussi il est peut être temps d’expliciter mes cibles habituelles.

Les paliers

100 milli-secondes, l’instantané

La cible idéale c’est une réactivité inférieure à 100 milli-secondes. C’est le palier jusqu’auquel on a une perception d’instantané. À ce niveau on ne donne pas d’ordre à une machine, on a l’impression de travailler directement sur les objets. Sélectionner un item, appuyer sur un bouton, taper du texte, ouvrir une liste déroulante, tout ça doit être instantané.

Au dela ce ces 100 milli-secondes l’utilisateur perçoit l’attente. Il n’agit plus directement sur l’interface, on sait qu’on fait travailler la machine et on en attend la réponse.

C’est simple à tester via une démo de Ben : imaginez vous faire une suite d’actions et cliquez sur les différentes cases. À 100 milli-secondes ou en dessous on clique et on passe à la suite. Déjà à 200 milli-seconde on se surprend à attendre que la requête soit prise en compte avant de passer à la suivante. L’interface devient « lourde ». À 350 milli-secondes je ne m’imagine pas sélectionner plus de 10 items sans ressentir une frustration.

1 seconde, l’attente

À partir d’1 seconde les choses se détériorent et on est réellement interrompu dans la suite de nos actions. On a une réelle attente, dommageable. Aucun élément de l’interface ne devrait à mon avis dépasser ce palier et s’il y a besoin d’une action longue il faut alors prévoir une interface adaptée. Cela passe à priori par un lien ou un bouton, puis par un indicateur de chargement, par exemple un curseur qui change ou une icône animée.

Pensez y quand vous dessinez vos interfaces. Si vous donnez l’apparence d’onglets, de liste déroulante ou d’éléments classique d’une interface utilisateur, vous devriez rester sous les 100 milli-secondes mais en aucun cas dépasser la seconde. Si vous avez besoin de charger une nouvelle page complète ce n’est pas un onglet qu’il vous faut mais un lien ou un bouton.

10 secondes, la perte d’attention

Au delà de 10 secondes l’utilisateur perd le fil et ne garde plus son attention sur la tâche en cours. Je ne vois qu’un seul cas où on devrait accepter plus de dix secondes d’attente dans une application web, mais si le cas se présente, alors il faut un moyen d’annuler et un indicateur sur l’avancement de l’action demandée. En pratique la seule application sur le web c’est pour les indicateurs de téléchargement de fichier, que ce soit pour envoyer ou pour recevoir. Voir que sa photo est en train d’être envoyée et où on en est fait toute la différence.

Mais, pour les pages web ?

Les pages web sont similaires. Une sélection ou une action d’interface doit être immédiate, c’est à dire en dessous des 100 milli-secondes. Le plus souvent même les traitements qui demandent du réseau peuvent bénéficier d’un indicateur de prise en compte immédiat. Par exemple si je supprime un élément de mon panier, il peut disparaître de mon interface immédiatement sans attendre la réponse ajax. Ce n’est que quand aucune réponse n’arrive au bout d’une seconde qu’on va montrer à l’utilisateur qu’il se passe quelque chose.

Pour le reste si vous arrivez à tomber sous la seconde, l’utilisateur reste dans son flot d’actions et garde sa suite d’idée. C’est probablement une des cibles de Google pour son moteur de recherche et ses applications en ligne. Ce devrait être le cas pour tous les traitements javascript et l’essentiel des traitements Ajax. Dans l’idéal passer d’une page à une autre similaire ou revenir en arrière devrait rester sous la seconde. Cela impose de mettre un maximum d’item en cache pour que télécharger les items uniques n’impose pas plus que ce palier fatidique.

Charger votre page ne doit jamais prendre plus de 10 secondes, si l’utilisateur porte son attention à autre chose, il est tout à fait possible que cette autre chose soit le site du concurrent ou le moteur de recherche pour aller sur un autre site.

En pratique c’est plutôt vers les 3 à 5 secondes qu’il faut mettre sa limite haute. Un étude d’Akamaï montre que c’est à 4 secondes que le taux d’abandon devient trop important. Yahoo! a même des chiffres qui parlent de 5 à 9% d’abandons pour juste 400ms de perdus.

Dans quel contexte ?

Une fois les cibles faites, il reste à en déterminer le contexte. Sur quel type de connexion faut-il tester le site et comparer avec notre cible ?

Personnellement j’utilise une latence 50 à 70ms et 1 à 2mb/s. Ceci est pour des sites français avec un public en France métropolitaine. Chez nous l’ADSL est très répandu et la latence globalement assez faible.

Passez à l’international et il faudra diminuer très largement vos prérequis. Une ligne de 512kb/s avec une latence de 120ms n’est pas si rare (mais je sors de mon expérience donc à vous de trouver les bons chiffres). Atteindre des pages en moins d’une seconde, ou même moins de trois secondes devient difficile, mais les paliers psychologiques restent les mêmes et c’est ça qui importe.

Bien entendu c’est à vous d’adapter à votre contexte. Il est possible qu’il soit pertinent de prendre une connexion de moins bonnes qualité. Faites juste attention à ne pas vous laisser éblouir par la publicité ou par votre qualité de connexion personnelle. Rappelez-vous que personne n’est à 24mb/s.

Reste qu’après il faut tester sur ce type de connexion avec tous les navigateurs fréquents. Généralement ça se réduit à tester avec le plus lent : Microsoft Internet Explorer 6.

Si votre public est concerné, tester aussi avec le Safari de l’Iphone ou avec un Blackberry peut être pertinent. Là il faut diminuer le débit cible et augmenter la latence associée. Vous verrez que rester sous les trois secondes est loin d’être facile quand la connexion est mauvaise.