L’optimisation de la performance, une question de qualité [BDX I/O 2016]
Retour sur la conférence “Design de la performance”
Il y a maintenant 1 mois, le vendredi 21 octobre dernier, j’ai pu assister par l’intermédiaire de mon agence MOONDA à la belle journée de conférences BDX I/O sur “les technologies de demain”.
Initialement pensée pour les développeurs, BDX I/O (“Bordeaux Developer eXperience”) ouvrait pour cette troisième édition une nouvelle thématique de conférences : “Design, UI & UX”, et c’est ce qui a particulièrement expliqué ma présence.
Devant faire des choix drastiques en terme de programme (tout de même 57 conférences, ligthning talks et workshops dans 6 amphithéâtres différents !), j’avais décidé d’assister à la sélection de présentations suivante :
- Algorithmes : les nouveaux pouvoirs des développeurs
- par Fabrice Epelboin de Sciences Po / Yogosha — @epelboin - Design de la performance
- par Damien Senger de Raccoon Studio — @iamhiwelo - Trends UX 2016 : les 5 tendances à suivre cette année
- par Michel Rousseau de Microsoft — @rousseau_michel - Passage de certification Opquast : le pied à l’étrier
- par Delphine Malassingne d’Ekino — @nissone - Intégrer de l’UX et de l’UI design dans un projet informatique
- par Nicolas Dagot de Capgemini — @nicolasdagot - Découverte de Elm : un langage et une architecture
- par Julien Viala d’Ekino — @MrWildcard_ - UX pour l’IoT : nouveaux défis
- par Faten Habachi d’Ippon — @fatenh - “Mon client ne comprend rien” : et si en fait on ne comprenait rien à nos clients ? De l’UX pour les interactions humaines
- par Sami Lini d’Akiani — @fromzesofa - Design sprint : réglez tous vos problèmes en 5 jours ou moins
- par Renaud Forestié de Sud Ouest — @reuno
… ce qui occupe déjà pas mal une journée, je trouve :)
Design de la performance : pourquoi ne parler que de cette conférence ?
Réaliser un compte-rendu de journée de conférences sur un seul sujet peut paraître légèrement restrictif, mais je préfère me focaliser sur une présentation et en transmettre un point de vue personnel, détaillé et optimiste, plutôt que de balayer de manière neutre et superficielle l’ensemble des prises de paroles auxquelles j’ai eu la chance d’assister, ce qui ne leur rendrait pas justice non plus ;)
Alors, qui se cache derrière cette conférence inspirante à propos du “Design de la performance” ? Et bien, il s’agit de Damien Senger, designer et développeur web strasbourgeois, passionné de typographie web et créateur du studio Raccoon. Sa présentation était pleine de bon sens, de réflexions et surtout de pistes de travail. C’est ce genre de conf’ que j’adore : on ressort de là remis-e en question et boosté-e !
Les 5 idées que je retiens de cette conférence
J’ai mis à plat un “top 5” des points qui m’ont marquée. Cette sélection s’explique certainement par mon contexte professionnel :
- Je suis planneur stratégique en agence de communication digitale et je travaille chaque jour sur la conception stratégique et ergonomique de plateformes digitales sans pour autant les “grapher” ni les développer.
- En tant que professionnels d’agence, on évolue autant en solo qu’en équipe, on jongle entre l’objectif business du client d’un côté et les besoins et attentes de l’utilisateur de l’autre — en gros, on essaie de tout faire pour qu’ils se rejoignent :)
Du coup, pourquoi ce top 5 en particulier ? Parce qu’il va, je l’espère, faire évoluer ma façon de concevoir ces plateformes digitales avec mes collègues !
Point n°1. Nous partageons de nombreuses idées reçues sur la notion de “performance digitale”.
“La performance ? Un truc de dev.”
Une des premières idées reçues concerne le fait que la performance est forcément un “truc de développeur”, une problématique technique qui n’intéresserait que les nerds et qu’eux seuls pourraient régler. Et bien heureusement, ce n’est pas le cas ! La performance ayant un impact sur l’ensemble du projet, elle ne concerne donc pas que le développement : la performance s’anticipe en équipe, s’organise, se designe, se teste, s’optimise…
“Un site performant se charge vite.”
C’est également un a priori très répandu sur la performance. Cette dernière ne concernerait que la vitesse de chargement des pages d’un site ! Cette idée reçue explique d’ailleurs certainement pourquoi on pense souvent que la performance est un “truc de dev”… Or c’est une vision incomplète : par exemple, la performance peut aussi se mesurer par un minimum de clics avant de pouvoir profiter du service principal proposé par une application.
“La performance sert sur les marchés où la data coûte cher.”
On ne peut pas le nier mais penser cela est assez restrictif. La performance concerne tous les utilisateurs, sur tous les marchés. L’exemple le plus proche de nous est celui du Francilien qui essaie d’afficher une page Web sur son smartphone alors qu’il est dans le métro. Sa data ne lui coûte pas forcément cher, mais la charger péniblement lui cause une frustration certaine.
“La performance coûte cher à produire.”
Vue comme une surcouche d’un projet digital, la performance peut être jugée chronophage donc coûteuse. Il s’agit là d’un problème méthodologique : si la performance est traitée comme un pan à part entière du projet, elle ne doit pas prendre particulièrement plus de temps.
A ma question, Damien Senger propose d’ailleurs 2 réponses complémentaires : du côté des designers, ne pas perdre de temps à produire les maquettes de tous les écrans mais plutôt gagner 4–5 heures à travailler en modules et styleguides, pour réinjecter ces heures gagnées dans les tests et optimisations de la performance. Du côté des développeurs, il estime qu’intégrer tout de suite les bonnes pratiques d’optimisation technique ne prend pas plus de temps : il faut simplement s’y intéresser...
Point n°2. Nous pouvons — donc nous devons — designer la performance.
Quand on sait que 40% des visiteurs quittent une page Web si son chargement dure plus de 3 secondes, cette affirmation devient évidente. De nombreux réflexes sont donc à développer d’un point de vue technique, à propos des images, des polices de caractères, des requêtes, de l’interprétation du code…
Damien Senger donne des pistes concrètes : le chargement des variantes uniquement nécessaires d’une typographie, l’utilisation du local storage, l’optimisation des images par le CMS, le choix du bon format d’assets graphiques, le choix du bon format pour les typographies, la réduction des octets mais surtout celle des requêtes, la réflexion sur la politique de cache, l’utilisation de “srcset”, l’optimisation des assets avec des outils de workflow comme Grunt ou Webpack, le lazy-loading des éléments, le subsetting des fonts, l’optimisation du temps d’interprétation grâce au CSS modulaire, aux pseudo-éléments, à la méthodologie BEM, à l’utilisation du HTML5, à la lutte contre les div multiples… En bref, un belle liste que je vous invite à découvrir dans le détail dans la captation vidéo en bas de l’article !
Point n°3. Designer la performance passe souvent par designer l’attente.
Quand l’optimisation technique n’est pas suffisante, le design doit définir comment faire patienter l’utilisateur : c’est ce que l’on appelle le design de l’attente.
Nous avons pléthore de moyens d’agir sur le design de l’attente :
- Le travail des animations et transitions qui peut permettre de gagner 500 ms entre un clic et la lecture d’un média type vidéo pour atténuer la perception de son temps chargement (tout en travaillant l’équilibre pour que ce temps ne soit pas pris pour une latence)
- Le détournement de fonctionnalités typiques, par exemple l’upload de photos sur l’application Instagram qui commence avant même d’appuyer sur “Publier”
- Les choix drastiques en terme d’affichage ou non d’éléments sur des versions mobiles pour les alléger
- Le travail sur les formats des assets graphiques pour un chargement plus rapide
- L’apparition de squelettes de contenu lorsqu’il n’est pas encore chargé
- (…)
Point n°4. La relation designer-développeur est clé dans la gestion de la performance.
Les problèmes de performance ne se voient généralement pas au démarrage d’un projet. La performance se suit, se mesure et s’optimise tout au de la réalisation. C’est pour cette raison que la clé du succès est une bonne relation entre le designer et le développeur.
En effet, avec une bonne collaboration et une bonne communication, la problématique de performance sera beaucoup mieux gérée. Tout en respectant la zone de confort de chacun-e, le secret serait dans la priorisation. Ainsi, pour trancher dans un conflit designer-développeur, il faut établir des priorités business : qu’est-ce qui est le plus important ? Le temps de chargement de la page ? Le temps d’accès à une information donnée ? (…)
En répondant ensemble à ces questions, le designer et le développeur vont dans la même direction. Pour Damien Senger, le design de la performance, c’est du travail en équipe, des compromis, des propositions, de la modularité et des tests.
Point n°5. Le design de la performance n’est pas juste ou faux : tout est question de contexte et de priorité.
La priorisation, on l’a évoquée juste avant. Mais elle ne va pas sans la prise en compte du contexte qui nous permet d’ajuster le curseur en terme d’attentes utilisateurs.
Par exemple, vous travaillez sur un site de presse ? Le chargement de la police est indispensable, car c’est la typographie qui signe l’identité d’un journal. Vous travaillez sur un site e-commerce ? Le chargement des titres et des images passe avant tout, pour que l’internaute puisse rapidement repérer le produit en question…
En terme de méthodologie, le design de la performance doit se construire page après page, car chaque écran représente un contexte différent et donc des besoins utilisateurs différents en terme de performance.
De plus, au lieu de s’enfermer dans une logique desktop ou même mobile-first (c’est tendance !), le mieux serait de penser “content-first” : c’est-à-dire partir du contenu et le placer dans des contextes de consommation différents (avec les périphériques les plus contraints par exemple) pour déterminer les axes d’optimisation.
Finalement, la performance, c’est une question de qualité, non ?
Au fond, j’ai l’impression que notre plus grand défi est plutôt de déceler la notion de performance comme élément à part entière dans les briefs clients, qui privilégient souvent la richesse de l’expérience et l’immersion visuelle. Tout du moins, notre rôle est peut-être de pousser et défendre la performance, pour rendre un véritable service aux utilisateurs finaux.
Je pense d’ailleurs que l’on retrouve cette même posture dans la notion de qualité web, qui “représente l’aptitude d’un service en ligne à satisfaire des exigences implicites et explicites” des utilisateurs. C’est la définition donnée par Opquast, projet que je vous encourage d’ailleurs à découvrir. A noter qu’Opquast dédie une checklist à la performance Web mais elle est uniquement orientée “affichage rapide des sites”.
L’idée reste donc de proposer une expérience utilisateur de qualité, ce qui peut être optimisé petit à petit, par itérations. Les attentes des utilisateurs sont variées, dépendent souvent de leur propre environnement à un instant T, et bien souvent, elles ne sont exprimées que lorsqu’un “problème” se pose.
>> Alors soyons empathiques, anticipons les exigences des utilisateurs et proposons-leur des plateformes perform… euh, de qualité :)
La conférence est visionnable ici :
Vous pouvez retrouver le programme complet de BDX I/O ici et les conférences qui ont été filmées, ici.
Si cet article vous a plu, n’oubliez pas de le recommander ou de le partager !
