C’est le résumé de Steve Souders qui a été publié récemment. On y retrouve quatre affirmations tirées des conférences. Toutes parlent d’une corrélation importante entre les performances et le trafic ou le business du site web :

Microsoft

Microsoft a trouvé qu’un ralentissement de deux secondes implique une réduction 1,8 % du nombre de recherches par utilisateur. Cela semble peu, mais c’est accompagné aussi d’une réduction de 4,3 % du revenu par utilisateur, et là ça fait moins rire. Autrement formulé : un utilisateur clique moins sur les publicités d’un site lent que sur les publicités d’un site rapide.

Ça rejoint d’ailleurs Google qui prend en compte la performance dans son « quality score » pour adword (en gros un site lent paiera plus cher ses publicités parce que le pourcentage de clic est plus faible) et c’est finalement logique, on hésitera à partir ailleurs et à se laisser tenter si on remet pas en cause une longue et pénible session de navigation qui nous a permis d’arriver jusqu’à la page en cours. Si la navigation est rapide on hésitera moins à partir dans diverses directions pour revenir ensuite.

Avis aux sites qui se rémunèrent sur la pub, et aux agences de comm qui font des publicités ultra lentes sous prétexte d’avoir une meilleur qualité d’image.

Google

Google lui a affirmé que 400 ms diminuait de 0,59 % le nombre de recherches par utilisateur. Là je suis un peu étonné parce que finalement ce n’est pas très significatif (sauf à ralentir de plusieurs secondes, et encore) et parce que leur dernière communication à ce sujet était d’un tout autre ordre de grandeur. Ils refont d’ailleurs état de chiffres bien plus importants dans une autre conférence dans le même événement. J’attends donc de lire leur communication complètement pour juger de ce que cela implique et de comment comprendre leurs différents chiffres qui ne semblent pas dire la même chose.

Par contre Google fait état d’un fait d’importance : les utilisateurs qui ont subit ce ralentissement minime de 400 ms continuent de faire moins de recherche sur le long terme même après que ce ralentissement soit supprimé. En gros vos performances actuelles vous impactent non seulement maintenant mais aussi dans le futur. Le chiffre avancé parait faible mais il a beaucoup d’implications et le contexte de Google est très particulier, j’y reviendrai donc certainement dans un billet dédié.

AOL

Sur le réseau AOL les 10 % d’utilisateurs qui ont les meilleures performances visitent moitié plus de page par session que les 10 % avec les moins bonnes performances.

Autant dire que cela a un impact sur le trafic des sites, et donc forcément la conversion en clic publicitaires ou en achats. Le chiffre est important mais il peut revêtir plusieurs formes, je vous en dirai plus quand j’aurai là aussi lu leur présentation à tête reposée.

Shopzilla

Enfin, Shopzilla a réduit le temps de chargement de 7 secondes à 2 secondes. C’est une différence importante et ça a donc du nécessiter des efforts conséquents, mais le résultat est là : 25 % d’augmentation de trafic, 7 à 12 % d’augmentation sur les revenus, et 50 % de réduction sur les coûts matériels.

À défaut d’être une formule magique, investir dans l’amélioration de la performance *doit* être considéré après lecture de ces chiffres. Payer une étude quelques milliers d’euros et un développeur interne pendant quelques jours/semaines pour corriger ce qui a été trouvé, cela peut assez facilement se révéler un investissement payant à court terme.

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.

Empilement de protocoles

Non, vous n’avez pas 24Mb/s. Dans l’idéal, si vous n’avez aucune perte et si vous utilisez le maximum théorique de votre ligne, vous avez entre 15 et 16Mb/s. Le tour de passe passe c’est qu’on ne parle pas de la même chose. 24Mb/s c’est le débit possible en ATM. ATM c’est le protocole utilisé en interne par votre FAI pour faire passer vos données.

Ce que vous utilisez vous c’est de l’IP. Il va falloir encapsuler vos données IP dans un flux ATM, en gros jouer aux poupées russes. Votre poupée à vous c’est la petite à l’intérieur, et s’il faut faire transiter la grosse extérieure, vous vous rendez bien compte que vous allez pouvoir en faire passer moins que prévu. En réalité la perte est entre 20 et 25%. Chez Free.fr, si on en croit les chiffres publiés sur leurs publicités, c’est 22% de moins.

Bref, 24Mb/s ? que dalle, c’est dans les 18Mb/s. En réalité encore moins parce que dans un trafic IP il y a aussi une partie liée au protocole. En prenant TCP et IP, on perd alors minimum 2 à 3% par paquet. En réalité nombre de paquets ne sont pas remplis au maximum, et il faut aussi compter des paquets de contrôle. Pour une utilisation « web » (hors vidéos et téléchargements) c’est dans les 90% de trafic utile seulement. Nous voilà tombés à 16Mb/s.

Qualité de ligne

Tout le monde n’a pas ces 16Mb/s non plus. C’est un débit théorique au plus proche du DSLAM. Malheureusement la courbe du débit théorique en fonction de la distance n’est pas proportionnelle. Après 1km le débit chute drastiquement. Un petit graphique vaut mieux qu’un long discours.

Des DSLAM il n’y en a pas sur toutes les rues. Même à Paris il est assez facile de dépasser le kilomètre. En plus petite ville, et particulièrement en bordure d’une ville de moyenne importance, la distance peut facilement exploser, et le débit faire l’opération inverse. 16Mb/s ? oubliez, beaucoup sont à moins de 8Mb/s. Demandez autour de vous de faire des tests de débits, vous pourriez être surpris.

Reste qu’on parle toujours d’un débit théorique sur une ligne optimale. Votre ligne n’est pas optimale. Suivant le diamètre de votre cuivre qui vous connecte au DSLAM et son environnement électromagnétique, vous pouvez avoir plus ou moins de bruit parasite. L’ADSL est génial dans le sens qu’il gère ce bruit et sait tout seul diminuer la bande passante pour assurer la qualité de la communication, mais ça fait autant en moins sur votre bande passante.

Pas que l’ADSL

Plus répandus, il y a une grande partie des internautes qui sont connectés par WIFI. Là aussi la qualité de la ligne compte, et non vous n’avez jamais les 54Mb/s promis. Si vous en avez le tiers vous pouvez être heureux. Le wifi b encore très répandu c’est 11Mb/s théorique, 6 réels dans de bonnes conditions. Ajoutez quelques murs, un étage, et les dégats commencent même si vous êtes à 200 mètres du DSLAM.

En progression il y a aussi la 3G et les terminaux mobiles. C’est du 3,6Mb/s théoriques, rarement plus de 2Mb/s en pratique car là aussi il y a un affaiblissement avec la distance. Cette bande passante est attribuée par cellules pendant un certain laps de temps. Vous êtes loin ? vous utilisez plus de cellule. Vous faites juste une requête ? la cellule vous est quand même attribuée. Vous ne demandez pas beaucoup de bande passante ? vous risquez d’utiliser des tranches de façon incomplète.

Je suis sympa, en réalité il y a encore des entreprises avec des lignes 256kb/s (ne vous moquez pas, la garantie de fonctionnement n’est pas la même) et des particuliers avec du RTC.

Empilement des requêtes

Allons encore plus loin. Levez la main ceux qui ont un client P2P qui tourne ? ceux qui ont la fille ou la petite soeur qui regarde ses vidéos ? ceux qui regardent la TV par ADSL ? ou simplement ceux dont le conjoint surfe aussi à partir d’une autre machine ?

La bande passante est partagée. Le P2P est un énorme consommateur de bande passante, avec une utilisation très peu efficace. La vidéo, ou même le surf, c’est autant de moins pour vous. Vous êtes 3 ? divisez par 2 la bande passante si vous surfez. Même chose si vous surfez avec plusieurs onglets en train de charger en parallèle, ou si vous cumulez plusieurs logiciels qui font appel au réseau. Si les autres font du téléchargement ou de la vidéo c’est facilement par 5 ou 6 qu’il faudra tout diviser. La TV par ADSL c’est 5Mb/s qui partent en fumée (et là ce n’est pas du maximum théorique, c’est du mesuré).

C’est vrai pour votre ADSL, ça l’est encore plus pour le WIFI ou la 3G. Là les fréquences sont limitées. Si quelqu’un utilise la 3G ou le WIFI, c’est tout le monde qui est impacté. Pour le WIFI peu importe que ce soit une autre borne wifi qui est utilisée, ce sont les mêmes fréquences, la même bande passante commune. Il ne vous reste plus qu’à espérer que personne ne regarde une vidéo en boucle par wifi dans votre immeuble.

Encore des contraintes techniques

Voilà votre 24Mb/s bien réduit. Une peau de chagrin qu’il reste avec tout ça. Parce que nous parlons toujours de bande passante maximale. En réalité vous n’atteignez pas la bande passante maximale qui vous reste.

Le serveur web en face ne délivre pas du 10Mb/s à tout le monde. En fait hors les quelques très gros sites, c’est déjà bien s’il a 10Mb/s garantis à partager entre tous ses clients. Les plus gros c’est 100Mb/s par serveur, à partager entre 50 à 300 clients simultanés. Faites le compte vous même.

Après vous ajoutez les contraintes de TCP/IP, qui font que la bande passante idéale entre le serveur et le client n’est pas utilisée immédiatement. Sur des petits contenus vous ne l’atteignez pas, quoi qu’il se passe.

Le résultat ?

Le résultat c’est que vous n’avez très probablement pas plus de 10Mb/s sur votre ligne ADSL, moins sur votre WIFI, et moins de 2Mb/s sur du 3G. Que tout ça est à partager entre tout le monde et avec votre TV sur votre modem ADSL, ou avec tout votre quartier pour le WIFI et la 3G. Et que vous n’utiliserez pas efficacement ce qu’il vous reste si ce que vous faites c’est du surf web.

24Mb/s.. vous rigolez ? c’est de la communication, pas de la réalité.

Il va être fréquent d’avoir assez peu. Pour mes tests je prend fréquemment 2Mb/s comme référence. Je sais que je suis bien au dessous de ce que les geeks ont, ceux qui choisissent leur appartement en grande ville en fonction du DSLAM, mais j’ai encore peur d’être au dessus du débit pratique médian d’une session de surf.

Là bien sûr je parle d’une représentation du public français. Pour de l’international ce serait encore pire, car quoi qu’on vous dise la France est plutôt en avance de ce côté là.

Oh, dernière chose … On parle en Mb/s, mega bits par secondes. Pour obtenir des Mo/s, il faut diviser par 8. Oui, mes 2Mb/s c’est 250ko/s.

La mesure

J’ai donc repris les chiffres de vendredi dernier et j’ai tenté de mesurer combien de temps est pris par cette page HTML principale. Je compte le temps de la requête, la latence, le temps de génération de la page, et le temps de téléchargement du code source.

Voici mes résultats :

Le cas France Telecom

Encore une fois, le temps pour France Telecom est pris en comptant les redirections sur la page d’accueil, et on voit ici bien pourquoi. Ces redirections plombent complètement le site puisqu’elles représentent 3,6 secondes, sur un total de 10 secondes. C’est délirant, et sans justification aucune vu la simplicité qu’il devrait y avoir dans un système de redirection de pays comme celui ci.

Sans ses redirections on arrive à 90 milli secondes sur un total de 6 secondes environ, donc un poids relatif de la page d’accueil inférieur à 2%.

Les deux catégories

Ce qui m’intéresse c’est deux choses :

Tout d’abord on voit que les seuls qui ont une page d’accueil significative sont ceux qui ont déjà travaillé et optimisé le côté client, et qui s’en sortent avec des performances bonnes ou honorables. Bref, avoir un bon rapport contenu / poids total est un bon critère de réussite.

Ensuite on voit que dans les autres, la page d’accueil, son poids, et le temps pour la générer, n’ont quasiment aucune influence significative sur le temps de chargement subit par l’utilisateur. Ce n’est clairement pas ça qu’il faut optimiser et vous pouvez laisser votre ingénieur et ses micro optimisations applicatives de côté (sauf si vous êtes à France Telecom).

La conséquence

Le temps de génération de la page représente une part infime, et il vaut mieux gagner 5% dans le reste du chargement que de gagner 50% sur le temps de génération de la page principale. La chance c’est que non seulement c’est plus rentable mais c’est aussi plus facile. Souvenez-vous, smushit c’est 10 minutes de travail pour une efficacité bien plus importante que ça.

Bref, travaillez sur le côté client, le retour sur investissement est bien plus important, bien bien plus.

Les mesures

Aux sites représentatifs j’ai arbitrairement ajouté France Telecom. Il s’agit pour moi d’ajouter une valeur haute, pas si rare que cela. J’ai d’ailleurs aussi compté la redirection de leur page d’accueil et je tiens à signaler que leur performance est très aléatoire, de 5 à 17 secondes.

Les mesures sont toutes prises avec Yslow, en premier accès (cache vide), en retenant la médiane d’une dizaine de tentatives. Là aussi j’ai eu parfois des résultats assez aléatoires, principalement à causes des publicités (mais l’utilisation de la médiane permet qu’ils ne faussent pas les résultats).

J’ai pris comme base un navigateur à deux connexions simultanées (Firefox 2, Internet Explorer 6), ce qui reste encore le mode d’accès le plus fréquent. Le réseau est un réseau wifi G 54mb/s à quelques mètres de la borne, et derrière une ligne ADSL avec une bonne connexion. La latence aller-retour lors du test est de 7ms entre mon poste sous WIFI et free.fr, mon FAI. Mon poste est récent, le processeur non utilisé, et suffisament de RAM libre pour faire tout ce que je souhaite. Bref, certains ont des conditions plus avantageuses mais les mesures sont prises dans des conditions plus que favorables, meilleures que la moyenne des français.

Le résultat

On perçoit tout de même trois catégories, avec les trois gros qui sont en dessous des 2 secondes parce qu’ils ont compris que c’est critique, les suivants qui prennent en compte les problématiques de performance et qui sont en dessous des 4 secondes, et les autres avec quelques résultats dramatiques. Je reste toutefois surpris du mauvais score de Le Monde, sachant que dans l’équipe il y a au moins un technicien au fait de ces problématiques et très compétent.

N’oubliez pas, 3 secondes c’est important, à partir de 4 secondes les abandons sont fréquents. Les gros remarquent des impacts significatifs sur leurs ventes et sur leur trafic pour des dixièmes de secondes.

Pour les utilisateurs bas débit c’est une horreur. Le point positif c’est que pendant ce temps nos débits ont explosé et la latence des connexions a diminué. Bref, au final le temps moyen de chargement des pages des utilisateurs haut débit a légèrement baissé, mais c’est au prix d’un enfer pour tous les autres (le chiffre US est de 40% de RTC, en France il est plus faible mais non négligeable). A t’on bien fait ? pas certain.

Qu’y a t’on gagné ?

Si on y a gagné ces dernières années quand on surf ce n’est pas en performances mais en richesse et en qualité. Ou pas d’ailleurs. C’est ce que sous entend l’étude mais je ne peux m’empêcher de faire le parallèle avec nos micro-ordinateurs et nos logiciels. La puissance a vraiment explosé mais ce n’a pas tellement été pour faire les tâches plus rapidement. On s’est retrouvés avec de véritables monstres logiciels qui ont mangé chaque année la puissance gagnée. C’est au point où il est presque plus agréable de faire du traitement de texte sur un vieil ordinateur que sur la toute dernière bête de course associée aux derniers logiciels.

J’exagère mais l’esprit est là et je me demande si sur le web ce n’est pas la même chose. Peut être qu’on n’y a pas vraiment gagné en qualité mais que les développeurs font simplement moins attention. La seule exception que je vois c’est pour les vidéos, où là il y a vraiment eu un gain sensible pour le visiteur.

Des chiffres…

L’étude me donne ne fait à moitié raison, sans le dire. En 2006 les statistiques font état d’une page moyenne de 280 balises HTML pour 1440 pixels de haut. C’est beaucoup tout ça pour … 500 mots en moyenne. Ca fait deux mots par balise. Le rapport signal/bruit est agaçant. Pour des lignes de 15 mots on a environ un tiers de la hauteur seulement occupée par le contenu texte, c’est peu. Je ne vous propose pas de vous rassurer parce que entre 2006 et 2007, si le nombre de pages en tableau a été divisée par deux, le nombre de balise a suivi le chemin inverse : on passe à presque 600 balises par page en moyenne. Personnellement je n’ai pas eu l’impression que ça s’est traduit par plus de contenu dans les pages donc on doit être à plus d’une balise par mot en moyenne. De quoi donner des vertiges.

Mais ce n’est pas tout parce que sur nos 300Ko de page web on compte en moyenne 50ko sur 7 javascript (compressé), 10ko sur deux fichiers de style, plus les images, qui représentent 75% des requêtes (donc pour ceux qui suivent, à peu près 30 images par page).

Une saturation

J’hésite à continuer. Nous sommes des vrais malades.

Et si nous nous arrétions là ? je ne parle pas des chiffres de l’étude mais des délires des concepteurs web. Il est temps que nos machines ultrapuissantes connectés avec 1500 fois le débit que j’avais en 97, commencent à être plus rapides qu’à l’époque non ? Commençons à faire de la qualité et du contenu ou lieu de nous vautrer dans toute cette puissance pour faire quelque chose d’à peine mieux.

Un espoir

On peut toujours voir les choses sous plusieurs angles, alors voilà le bon : si réellement on a encore en moyenne deux feuilles de style, sept fichiers javascript et tant d’images, alors il y a une très bonne marge de progression côté performance pour un investissement très minime : concaténation des fichiers css, des fichiers javascript, et sprites pour les images.

Simple à mettre en oeuvre… en attendant de mettre fin au reste des délires.