Sur la performance Web et l'expérience utilisateur

Depuis deux ou trois ans, la notion de performance des sites et des applications Web a fait son entrée dans l’expérience utilisateur, mais également dans le référencement. La prise de conscience de la nécessité d’un Web “qui ne rame pas” est arrivée d’un peu tous les côtés, jusqu’à devenir une préoccupation majeure des éditeurs, à mesure que les utilisateurs s’habituaient à obtenir leurs pages quasi instantanément.

Contrairement aux standards du Web et au couple (X)HTML/CSS VS tableau + style inline, les préoccupations autour des performances ont pris très rapidement car elles avaient un impact financier direct : une étude de Forrester montre ainsi qu’un temps de chargement de plus de 3 secondes entraîne 40% d’abandon de panier en plus.

Comment en est-on arrivés à ce “culte de la performance” ?

Oubliez les histoires de “Web temps réel”, instantanéité de l’information et autres flans marketing que l’on nous sert avec plus ou moins de conviction depuis deux ans, ça n’a rien à voir avec la choucroute.

Pour comprendre ce besoin de besoin de performance, il faut plutôt se tourner vers l’adoption du Web en tant que média de masse, et son intégration dans notre vie quotidienne. Tant que le Web restait quelque chose d’expérimental – aux yeux du grand public – une simple source d’informations supplémentaire ou remplaçait un usage existant, les utilisateurs acceptaient la lenteur puisqu’elle affectait quelque-chose considéré comme superflu. Au contraire, aujourd’hui, le Web s’est intégré à des usages existants au point de les transformer : presse écrite, courses au supermarché, communication… Dans le même temps, les entreprises ont commencé à remplacer leurs applications informatiques traditionnelles par des applications Web, faisant de ce dernier un composant stratégique de leur fonctionnement. Ce qui était superflu est devenu la norme – le nécessaire – et l’attente n’est plus tolérable.

À cela sont venus s’ajouter deux éléments :

Le débit disponible sur les lignes domestiques a explosé en quelques années, la norme passant de 512Kb/s à 8Mb voire 20Mb, rendant la lenteur de chargement “anormale”. Comme si je faisais de meilleures photos parce que mon appareil numérique avait plus de mégapixels…

L’e-commerce a révolutionné la vente par correspondance en supprimant l’intermédiaire de l’envoi du courrier dans l’acte d’achat. Même si la vente se faisait également par téléphone depuis plusieurs années, l’opératrice rajoutait un intermédiaire que le Web a définitivement supprimé.

Dans l’expérience utilisateur, la notion de performance s’exprime de plusieurs manières différentes :

• Le temps nécessaire à générer et charger une page Web.
• Le temps nécessaire à télécharger tous les éléments de la page.
• La fluidité du navigateur dans la manipulation des éléments de la page.

Le temps de génération de la page et de chargement des composants par le client peuvent être facilement mesurés. Ces temps de chargement doivent évidemment prendre en compte le débit disponible entre le client et le serveur. En 2010, mesurer la rapidité d’une page à l’aune d’un modem 56K n’est peut-être plus vraiment nécessaire, même si…

Plusieurs outils sont disponibles pour mesurer ces éléments, à commencer par le très pratique Firebug, dont la section network donne un aperçu très précis de la séquence de chargement de la page. Deux extensions pour Firebug sont également disponibles, qui interprètent les résultats du chargement de la page à l’aune d’une série de bonnes pratiques, sans se baser sur la vitesse de chargement : Yslow, de Yahoo! et Page Speed de Google. Vous pouvez également tester votre site directement en ligne avec Gmetrix qui offre un tableau comparatif des résultats obtenus par les deux outils.

Les bonnes pratiques de Yslow et de Google Page Speed sont toutefois à relativiser : ce sont des guides généraux qui ne s’appliquent pas forcément à tous les sites Web, il ne faut donc pas les prendre au pied de la lettre, et certaines peuvent même aller à l’encontre des effets désirés. La mise en place d’un CDN, par exemple, peut ralentir les temps de chargement si les serveurs du CDN sont situés trop loin du client ou sur des lignes de transit pourries.

Depuis qu’il a introduit le temps de chargement dans son algoritme, les Google Webmaster Tools proposent un graphique résumant les temps de chargement moyens des pages d’un site, accompagné de conseils d’optimisation des pages les plus significatives.

Ce graphique a pour intérêt qu’il prend en compte le temps de chargement de toute la page, éléments externes compris (ce qui peut également être trompeur). Ici, par exemple, on constate un premier pic dans les temps de chargement le jour où j’ai installé le bouton Like de Facebook, et un second le jour où j’ai installé le bouton Open Dislike. Ces deux boutons ont beau être chargés dans une iframe, cette dernière rentre en compte dans le temps de chargement global de la page. Mais ce n’est pas vraiment mon propos, il existe énormément de très bonnes ressources sur le sujet, à commencer par le blog d’Eric Daspet, et pour le côté serveur, le MySQL Performance Blog.

Si les composantes serveur peuvent être calculées de manière assez précises, la fluidité d’une application côté client reste très subjective. Une application très rapide, mais à l’interface très chargée paraîtra plus lourde qu’une application un peu plus lente, mais un peu plus simple. L’introduction de vidéos, d’objets Flash et d’effets Javascript dans les pages a eu pour effet d’en alourdir le fonctionnement côté client, les navigateurs anciens pouvant avoir du mal à interpréter le contenu de la page, et notamment les interactions entre le Javascript et le DOM. C’est la raison pour laquelle il est très important de bien répartir la part de glitter et de purement fonctionnel.

Une fois encore, les bonnes pratiques sont à aller chercher du côté des sites de vente en ligne, Amazon en tête. Le site utilise quelques effets, idéalement placés, essentiellement un menu déroulant, et de carousels. Chacun de ces éléments donne une impression de rapidité incroyable, y compris sur des navigateurs anciens, et le défilement de la page n’en est jamais ralenti. Les effets ne sont pas là pour faire joli, ils servent les objectifs business d’Amazon.

L’explosion du Web mobile a marqué un sérieux retour en arrière, notamment en termes de débits possibles et de ressources sur le client. Ce n’est pas vraiment étonnant, mais cette régression n’a pas vraiment eu les conséquences attendues. Au lieu de créer des versions mobiles de leurs sites ou applications Web très légères et optimisées, les éditeurs se sont tournées vers des clients spécifiques aux principaux systèmes d’exploitation mobiles : Android, Blackberry, Symbian, iPhone et Windows Mobile.

Ce n’est finalement pas vraiment étonnant : passer par une application permettait d’embarquer tous les composants structurels des pages sur le téléphone, et de limiter le téléchargement aux seules contenus à consulter. Cela permettait d’accélérer l’affichage des informations tout en économisant les forfaits data des utilisateurs. Cela prend également en compte le fait que les utilisateurs restent globalement peu habitués à utiliser un navigateur sur leur téléphone mobile, alors que la présence d’applications n’est plus une nouveauté depuis longtemps. Il reste qu’entre une ergonomie souvent douteuse et les lenteurs inhérentes à la plate-forme d’utilisation, l’expérience utilisateur est très loin d’être satisfaisante.