Le 9 octobre dernier se tenait la première édition de We Love Speed, premier événement français dédié à la Performance ou Webperf.
Cet événement à destination des professionnels du web, de l’e-commerce et experts de la webperf est né de l’envie de partager le plus largement possible les connaissances et expériences en matière de webperf.
Le sujet de la webperf est très présent dans les réflexions des consultants Clever Age ; au travers de nos missions de conseil ou de mise en oeuvre nous accompagnons nos clients dans la prise en compte des enjeux de la performance web dès la conception des dispositifs web et tout au long de la vie des projets.
C’est donc tout naturellement que Clever Age s’est positionné très tôt en tant que partenaire et sponsor de We Love Speed. Au côté de sponsors prestigieux comme Google, CDiscount, Fasterize, Dareboost, Akamai… nous sommes fiers d’avoir accompagné les organisateurs pour cette première édition.
La journée We Love Speed rassemblait les talks d’une dizaine d’experts de la webperf, voici une synthèses des talks par nos consultants présents à la conférence.
Quelles métriques pour mesurer la webperf ?
Par Jean-Pierre Vincent
Pour avoir des mesures utiles il n’est évidemment pas possible de mesurer ce que ressent l’utilisateur devant une page web, mais de mettre en place des mesures pratiques, chiffrées, compréhensibles par les différents intervenants et qu’elles soient représentatives de l’UX et qu’elles représentent le business.
Voici les différents indicateurs présentés par Jean-Pierre :
- Temps de chargement : peu représentatif de l’expérience utilisateur
- First Paint : Premier pixel non blanc qui apparaît à l’écran
- First Contentful Paint : Premier pixel non blanc qui appartient à une image ou à un texte
Ces deux indicateurs sont récupérables via des outils (WebPagetest, Lighthouse) ou via des APIs JS. Ces deux indicateurs ne représentent que la première étape du chargement d’une page ;
- SpeedIndex : Addition de pourcentages de pixels multipliés par le nombre de secondes pendant lesquelles ces pixels sont affichés. Moyenne des top 40 médiane autour de 6300 et l’objectif de Google est un SpeedIndex (100 % des pixels finaux) en moins d’une seconde. Une limite du SpeedIndex est d’être perturbé par des animations, vidéos, carrousel, popin.
Les mesures suivantes permettent de savoir à partir de quand la page est utilisable :
- DomContentLoaded : événement utilisé par les développeurs JQuery, récupérable via des outils (RUM) ou via api js.
- First Meaningful Paint : Évalue le moment où des framework comme React calculent le plus grand nombre de nouveaux layout visibles dans le viewport. Uniquement disponible dans Chrome et pas représentatif sur tous les sites.
Les indicateurs suivants permettent de mesurer la réactivité de l’interface :
- First CPU Idle : Début des 5 premières secondes de CPU calme
- Time To Interactive : Début des 5 premières secondes de CPU calme et une période de réseau calme
- Fist Input Delay : Temps de réaction au clic : Nombre de ms entre le moment où l’utilisateur clique ou scrolle et l’exécution de la première fonction associée. Cette mesure n’est disponible qu’en RUM.
Ces indicateurs génériques doivent être validés dans le contexte de votre site pour vérifier qu’ils sont pertinents et adaptés au monitoring de la webperf de votre site.
Ces indicateurs peuvent être complétés par la mise en place de Custom Metrics pour mesurer des “moments” particuliers du chargement d’une page : affichage du logo ou de l’image produit, démarrage d’un tracker , disponibilité d’une fonctionnalité (moteur de recherche). Ces metriques sont plus précises et plus alignées avec les objectifs business.
Les Custom Metrics sont récupérées en js via le standard User Timing qui permet de marquer ces points particuliers et de les rendre accessibles via Webpagetest par exemple. Pour mesurer des événements comme par exemple le chargement d’une pub ou d’une fonte, il est également possible d’analyser les requêtes HTTP.
Jean-Pierre conseille d’implémenter ces métriques proches de votre métier, facilement communicables en interne même si leur maintenance nécessite du développement et de la rigueur.
Un talk d’introduction qui permet de bien rappeler les différentes métriques utiles pour mesurer la performance d’un site et qui seront reprises tout au long de la journée dans les différentes présentations.
L’UX au service de la performance de vos interfaces
Par Stéphanie Walter
Slides disponibles à ce lien
Stéphanie Walter est UX et UI designer, avec une expertise particulière sur le mobile et la performance. Elle avait d’ailleurs déjà animé, en duo avec Jean-Pierre Vincent, la conférence « Stratégies d’adaptation mobile : ergonomie, UX et performance en milieu périlleux » à Blendwebmix en 2015.
Cette nouvelle conférence de Stéphanie est axée sur la perception de performance, une prise de recul salutaire à côté des mesures très techniques mises en avant le plus couramment quand on parle de performance Web, et qui rejoint le besoin présenté par Jean-Pierre juste avant de trouver des indicateurs de performance réellement significatifs par rapport au ressenti des utilisateurs, mais mesurables techniquement (pour permettre l’automatisation, notamment).
Profitant de retours d’expérience très concrets, Stéphanie présente de multiples techniques permettant de donner une illusion de performance, quand la performance effective n’est pas complètement au rendez-vous, et qu’il n’est plus possible techniquement (ou pour des raisons budgétaires et/ou de délai) de l’améliorer.
Globalement, l’idée est d’occuper l’esprit des utilisateurs quand on les fait attendre, pour que cette sensation désagréable d’attente soit minimisée, voire disparaisse. Cela va de « simples » animations à des mises en scènes plus riches, profitant de ce temps d’attente incompressible, en faisant une opportunité plutôt qu’une faiblesse.
Stéphanie présente également comment organiser le travail entre les concepteurs UX, UI et les développeurs, comment faire en sorte que chacun connaisse les possibilités et contraintes des autres, etc.
La conférence se termine sur un point contre intuitif, montrant qu’il faut parfois au contraire travailler sur l’UX pour masquer une performance technique trop bonne, la valeur accordée au résultat dépendant souvent de l’effort nécessaire — ou plutôt perçu comme tel — pour l’obtenir.
Au final, une excellente conférence qui montre une fois de plus que la technique n’est qu’un des vecteurs de performance, au service de l’UX, et que les équipes doivent travailler ensemble.
Les performances de rendu CSS
Par Thomas Zilliox
Slides disponibles à ce lien
Thomas Zilliox est un développeur web expert en technologie front qui se revendique “expert CSS”, et pour cause ? Il reste en recherche perpétuelle de simplicité, maintenabilité et modularité des langages CSS et Javascript. Il partage son expertise et ses trouvailles au cours de conférences, d’articles en ligne et aussi récemment au travers du livre : « Départ immédiat pour : Flexbox »
Dans cette conférence intitulée “Les performances de rendu CSS” Thomas s’attarde sur l’impact des diverses propriétés CSS appliquées à une page web d’un point de vue performance. L’idée est de ne plus minimiser, comme trop souvent, l’impact d’une optimisation des feuilles de styles. On cherche à optimiser chaque propriété pour garder une interface fluide lors du défilement, de manipulation de contenu et pendant la transition d’un contenu à l’autre.
La recommandation proposée par Thomas est de s’interroger sur les impacts de chaque propriété CSS ; et sur les choix de développement front-end en général ; pour opposer leurs apports à l’interface par rapport à leurs coûts en performance. Exemple : AirBnB à supprimé ou réduit les ombres appliquées à la majorité des blocs du site car ces dernières dégradent les performances de rendu de page lors du défilement.
Une réflexion orientée performance pour le CSS induit de disséquer la méthode de fonctionnement d’affichage d’une page web par un navigateur : Layout – Paint – Composition – Pixels (Modèle issu de la conférence). C’est l’ensemble de nos propriétés CSS qui vont définir notre affichage final une fois toutes les étapes du modèle présenté effectuées par le navigateur. Les interactions avec notre page vont quant à elles modifier l’affichage de notre page déjà chargée et donc relancer une ou plusieurs étapes de processus d’affichage du navigateur. Chaque étape représente des ressources supplémentaires, et c’est pourquoi il faut judicieusement les choisir. Voici la ressource partagée par notre expert CSS pour associer chaque propriété aux divers évènements navigateurs qu’elles engendrent : CSS Triggers.
Thomas nous appelle ici à adopter une nouvelle méthode de réflexion pour construire nos feuilles de style : anticiper les coûts – chercher des contournements ou optimisations possibles – appliquer de manière à être le plus minimaliste et maintenable possible – tester les performances de l’approche adoptée sur l’ensemble des navigateurs compris dans le scope projet.