“L’ergonomie n’est plus négociable aujourd’hui”. OCTO Technology
Il existe une conviction partagée chez les grands du Web : la performance perçue par l’utilisateur est critique. Cette performance a en effet un impact direct sur l'adoption du service et son utilisation dans la durée. Et le ressenti utilisateur est directement lié à la rapidité d’affichage des interfaces.
Le grand public se moque bien de l’architecture logicielle, de la puissance des serveurs, de la latence réseau provoquée par l’appel à des Web services... Tout ce qui lui importe, c’est l’impression de fluidité dans l’usage.
Les grands du Web l’ont bien compris et parlent ainsi de mesure en “battement de cils”. Tout se joue donc à l’échelle du 1/10ème de seconde. Leurs études, réalisées notamment grâce à du test A/B (cf. article à ce sujet), le démontrent clairement :
Suivant en cela le Pattern “device agnostic”, les grands du Web développent parfois des interfaces natives, parfois des interfaces Web, afin de toujours offrir la meilleure expérience utilisateur. Dans les deux cas, la performance perçue par l’utilisateur doit être maximisée.
Avec l’iPhone, Apple a réintroduit le développement au plus près du matériel (sans revenir à l’assembleur, tout de même) pour maximiser les performances perçues. Ainsi les technologies Java et Flash sont bannies de l’iPhone. La plateforme utilise aussi des artifices visuels : au lancement d’une application, il peut charger la vue du dernier état de l’application pour maximiser l’impression d’instantanéité, la véritable application étant chargée en tâche de fond. Sur Android, les applications Java sont exécutées sur une machine virtuelle optimisée pour la plateforme. Elles peuvent aussi être écrite en C pour maximiser les performances.
De manière générale, un consensus s’est dessiné autour du développement natif, en particulier sur plateformes mobiles : il doit être au plus près du matériel. Et des technologies multiplateformes comme JME, Flash ou Silverlight tendent à tomber en désuétude pour privilégier l’expérience utilisateur.
Le chargement complet d’un écran Web est souvent de l’ordre de 4 à 10 secondes tout compris (avec les images, le JavaScript, Le Flash, etc.)
Il apparaît que la lenteur d’affichage perçue est généralement liée pour 5% aux traitements sur serveurs, et pour 95% aux traitements du navigateur. Les grands du Web apportent donc un soin tout particulier à l’optimisation de l’affichage des pages Web.
Voici une liste des principales bonnes pratiques qui font consensus :
Les exemples d’usage du pattern sont nombreux chez les grands du Web : on peut citer Google, Gmail, Amazon, Yahoo, ...
Google possède le réseau de cache distribué le plus maillé des grands du Web : le géant de la recherche disposerait de machines dans toutes les grandes villes, et même d’un réseau privé mondial, selon des rumeurs difficiles à vérifier.
Google Search pousse l’expérience utilisateur temps réel très loin avec “Instant Search” qui charge les résultats de recherche au fur et à mesure de la frappe clavier. Cette fonction est une prouesse technique : elle a soulevé nombre de questions dans la communauté des architectes (cf. liens ci dessous).
Gmail est construit quasiment en HTML : les images de l‘interface sont réduites au strict nécessaire (2 “sprites” d’icônes, voir ci dessous), et le site fait un usage extensif du cache et du chargement JavaScript en tâche de fond.
Sites utilisant ou ayant utilisé le réseau de cache distribué (CDN) Akamai :
L’effet de la latence d’affichage est le même sur les applications internes, propres à une DSI : exaspération des utilisateurs et abandon du recours à l’application.
Le pattern s’applique donc parfaitement en interne.
Elles sont rares : on peut évoquer les applications asynchrones et les batchs.
Retrouver toutes les pratiques des Géants du Web sur le site dédié (www.geantsduweb.com) : pdf de l'ouvrage à télécharger, vidéo et compte-rendu de la présentation "Décrypter les secrets des Géants du Web"
Présentation “Performance des applications web, quoi faire et pourquoi ?” lors de l’USI 2010 : http://goo.gl/C57B8
Article sur Google Instant Search : http://highscalability.com/blog/2010/9/9/how-did-google-instant-become-faster-with-5-7x-more-results.html
http://googleblog.blogspot.com/2010/09/google-instant-behind-scenes.html