Pourtant j’ai remonté les archives pour vous. Histoire de prendre une figure connue j’ai pris Jakob Nielsen. Jakob est peut être le dinosaure de l’utilisabilité (ou usabilité, je vous laisse choisir votre terme). Il a ses détracteurs, ses défauts, mais il a le mérite de publier depuis plus de dix ans, et de garder une constance impressionnante dans ses préoccupations.

Dès 1996

Voilà, j’ai retrouvé une AlertBox de mai 1996 : les 10 plus grandes erreurs de design web. En dixième position on retrouve la question des temps de (télé)chargement :

I am placing this issue last because most people already know about it; not because it is the least important. Traditional human factors guidelines indicate 10 seconds as the maximum response time before users lose interest. On the web, users have been trained to endure so much suffering that it may be acceptable to increase this limit to 15 seconds for a few pages.

Even websites with high-end users need to consider download times: many B2B customers access websites from home computers in the evening because they are too busy to surf the Web during working hours.

Et par la suite

Avec l’augmentation des bandes passantes, de la puissance des machines, et la maturité du développement web on aurait pu s’attendre à ce que ça change. Mais non, on remet ça en 97, 99, 2000, 2004. En 1997 on a même la déclaration suivante :

Slow response times are the worst offender against Web usability: in my survey of the original « top-ten » mistakes, major sites had a truly horrifying 84% violation score with respect to the response time rule.

Bloated graphic design was the original offender in the response time area. Some sites still have too many graphics or too big graphics; or they use applets where plain or Dynamic HTML would have done the trick. So I am not giving up my crusade to minimize download times.

The growth in web-based applications, e-commerce, and personalization often means that each page view must be computed on the fly. As a result, the experienced delay in loading the page is determined not simply by the download delay (bad as it is) but also by the server performance. Sometimes building a page also involves connections to back-end mainframes or database servers, slowing down the process even further.

Users don’t care why response times are slow. All they know is that the site doesn’t offer good service: slow response times often translate directly into a reduced level of trust and they always cause a loss of traffic as users take their business elsewhere. So invest in a fast server and get a performance expert to review your system architecture and code quality to optimize response times.

Bref, rien de neuf sous le soleil, bien au contraire.

Et maintenant ?

Étonnament même maintenant, on trouve encore des sites qui prennent 10 secondes pour se charger. Test fait, je tiens d’ailleurs à présenter mes excuses à France Telecom que je souhaitais prendre en exemple dans ce paragraphe. Charger leur page d’accueil ne prend que 9,1 secondes (je n’ai pas trouvé de balise HTML pour marquer l’ironie teintée de provocation, j’ai utilisé l’italique et j’espère que toi aussi tu m’en pardonneras, bien heureux lecteur).

Encore maintenant ce sont les pages mal architecturées et l’indigestion de bidules inutiles qui sont la principale cause du problème. Encore maintenant, si on en croit Amazon, la lenteur a une réelle influence sur l’utilisateur.

Oh, on a fait du chemin. On en est à parler en général de 2 à 5 secondes au lieu de 10 à 15. Mais entre temps nos machines sont 20 fois plus puissantes, notre bande pasante est de 100 à 1000 fois plus importante qu’à l’époque, notre latence est souvent moitié plus faible elle aussi. Bref, il a vraiment fallu jouer aux idiots pour obtenir de si mauvais résultats. Oui je sais, je me répète, mais sur ce sujet trop vaut mieux que pas assez.

On parlait de 10 et 15 secondes mais c’est à une époque où le simple fait de se connecter était une réussite en soi. Désormais c’est l’usage courant et les attentes sont donc différentes. Demain il est peu probable que les gens accepteront d’attendre plus longtemps que quand ils zappent sur la télévision.

Il faut viser moins d’une seconde. Au delà de deux vous avez un problème, au delà de trois ce doit être une de vos priorités.

Les chiffres de base

Je me base souvent sur des chiffres glanés je ne sais plus où (probablement Jackob Nielsen mais je ne retrouve pas la référence) : moins de 100ms c’est instantané, entre 100ms et 1s on perçoit la notion de téléchargement ou de calcul de la page qui arrive, et supérieur à 1s on a l’impression d’attendre.

Reste que dans ma mémoire ces chiffres n’étaient pas spécifiques au web. L’utilisateur web est habitué à attendre dans certains contextes, et habitué à avoir ce qu’il cherche immédiatement dans d’autre contextes. La bonne question c’est donc de savoir en dessous de quelle valeur on a un avantage concurrentiel sur les autres, et à partir de quelle valeur nos visiteurs partiront effectivement chez les concurrents.

Ceux qui font prendre conscience

Je vous avais donné des chiffres il y a quelques temps. Ils permettent de sensibiliser les gens : Montrer que Google perd 30% de traffic quand sa page passe de 400ms à 900ms est assez percutant. Montrer que 100ms a un impact concret sur les ventes d’Amazon impose de ne pas compter qu’en secondes.

Maintenant ces chiffres là non plus ne sont pas suffisants. Un moteur de recherche est un site bien à part. Lire ces données permet de prendre conscience de l’importance des performances mais cela ne vous donne toujours aucune référence, enfin sauf si vous développez un moteur de recherche.

Et ceux qui peuvent servir de seuil d’alerte

C’est Akamai qui va nous donner une dernière catégorie de chiffres. Dans un communiqué de 2006 ils identifiaient un palier à 4 secondes. Au delà de ce chiffre, les utilisateurs commencent à abandonner. Voilà un exemple de limite haute, qui doit générer une alerte quand vous la dépasser.

Maintenant n’oubliez pas que les choses ont évoluées depuis 2006. Le français moyen a une connexion avec un meilleur débit qu’à l’époque, sa machine est plus puissante et il a moins l’habitude d’attendre. Bref, dépasser 4 secondes est probablement plus grave qu’avant.

Gardez aussi le contexte à l’esprit. Un utilisateur qui cherche une information et vient à partir d’un moteur de recherche risque de ne pas attendre 4 secondes, là chaque dixième de seconde compte.

Quoi faire de ces chiffres ?

Tous ces chiffres sont déduis de mesures réelles et à prendre en compte. Ils sont donc vrais en même temps. Surtout ne gardez pas à l’esprit que ces 4 secondes.

Vous devez toujours viser de meilleures performances, et garder à l’esprit que 100ms ou 500ms peuvent représenter une perte de chiffre d’affaire ou un tiers de traffic en moins. Vous devez toujours vous rendre compte à partir de quel moment l’utilisateur percevra l’attente. Mais en plus, maintenant, vous avez un palier à partir duquel vous pouvez juger la page inacceptable.