Performances web : du taux de conversion au taux d’inclusion

Ces quinze dernières années, le web a pris une direction claire : celle des grands groupes, des GAFAM qui refusent de payer des millions de dollars de taxes, de la collecte et de la revente de nos données personnelles, des algorithmes biaisés, de la surveillance d’état parfois. On est bien loin de l’idéal libertaire de Tim Berners-Lee, de l’idée que n’importe qui peut publier n’importe quoi sur le Web, et que n’importe qui doit pouvoir y accéder. Je suis peut-être nostalgique d’une époque révolue, mais cet idéal continue de me parler. Il constitue même l’une des raisons pour lesquelles je n’ai toujours pas abandonné le métier de développeur web.

Tout le monde doit pouvoir accéder à ce qui est publié sur le Web. Avec l’essor des smartphones, il semble que nous sommes tous de plus en plus connectés, partout, tout le temps. Néanmoins, en tant que développeur·euse web, nous savons que pour qu’un site soit vraiment accessible à tout le monde, ça demande du travail. Mais, même une fois que nous avons fait le nécessaire pour nous conformer aux normes d’accessibilité, il reste un aspect fondamental pour garantir un accès au Web à tout le monde : les performances.

En général lorsqu’on parle de performances sur le Web, les arguments qu’on entend le plus souvent sont les arguments « business » : de mauvaises performances ont un impact négatif sur les taux de conversion, augmentent le taux de rebond etc. Traduction : cela fait perdre de l’argent. On a pu voir de nombreuses études, avec moult statistiques à l’appui, sur comment Pinterest a augmenté son taux de création de compte de X% en améliorant la vitesse de sa page de recherche, ou comment [site Y] a gagné Z millions de dollars par milliseconde de latence gagné . Ces arguments, qui touchent directement le portefeuille, sont les plus susceptibles de parler aux chef·fe·s de projets et autres N+123 (ou à tout ceux dont on a indexé le succès au mouvement de certaines « KPIs »), et ce sont donc souvent les premiers arguments que l’on avance pour justifier un travail sur les performances.

Cependant, il y a pour moi une raison bien plus importante de se pencher sur les performances de son site web : l’inclusivité.

Lorsqu’on développe un site internet, on peut avoir tendance à oublier dans quelles conditions il sera utilisé. Prenons un exemple. Imaginons que je travaille pour une plate-forme de mise en relation entre des agriculteurs et des clients potentiels. Pour que ces agriculteurs puissent gérer leurs ventes et leur production, nous avons créé une interface de catalogue de produit, sur laquelle un producteur peut gérer ses stocks, ses points de vente et ses commandes. Rendue côté client avec beaucoup de JavaScript, la page n’est pas très rapide, mais, étant donnée sa complexité, on ne s’y attarde pas trop, d’autant plus que d’autres projets nous attendent, et qu’on a du pain sur la planche si on veut renverser la grande distribution.

Fast-forward deux ans plus tard. Il se trouve que pour renverser la grande distribution, nous avons besoin de rajouter des fonctionnalités à ce catalogue de produits. Pour s’assurer que notre idée est potentiellement une bonne idée, une spécialiste de l’expérience utilisateur (UX research) part à la rencontre d’un de nos agriculteurs, pour observer son utilisation du catalogue, et faire les premiers tests. Dans le compte-rendu de sa visite, un élément frappe toute l’équipe : une vidéo d’environ une minute, qui montre l’écran de notre producteur utilisant le catalogue. Le problème, c’est que la vidéo ne montre pas vraiment l’utilisation de la page, mais uniquement son chargement. Sur le vieil ordinateur de la ferme, avec une connexion digne du début des années 2000, notre site met plus d’une minute avant de s’afficher. Nous étions conscient du poids important de cette page, mais en la testant uniquement sur des ordinateurs avec plus de 8 Go de RAM et la fibre, nous étions très loin de nous rendre compte à quel point elle pouvait être lourde. Sur cette minute de chargement, environ la moitié était passée à télécharger et parser le JavaScript, et l’autre moitié à l’exécuter. Et ce producteur était obligé d’utiliser notre catalogue tous les jours.

Cette petite histoire m’a appris plusieurs choses. D’abord, pour savoir à quoi ressemble un site sur une mauvaise connexion et un vieil ordinateur ou un vieux téléphone portable, les simulations proposées par les navigateurs ne suffisent pas. Ensuite, et c’est bien plus important, les performances font partie des problématiques d’accessibilité d’un site web. Autrement dit, un site codé sans prendre en considération les performances va exclure une partie des utilisateurs d’Internet. Tout le monde n’a pas une connexion haut débit et stable. Tout le monde n’a pas un ordinateur avec 8GB de RAM. À une époque où tout se dématérialise, il devient essentiel de ne plus se contenter de vérifier que les performances d’un site sont acceptables sur le terminal sur lequel on le développe, mais sur tous les terminaux. Bien sûr, les entreprises n’ont pas des ressources illimitées, et nous nous retrouvons souvent à faire des compromis entre accessibilité et nouvelles fonctionnalités. Mais quand nous faisons ces compromis nous devons comprendre ce qu’ils impliquent : l’exclusion de certaines personnes.

En tant que développeur·euse·s web, je pense que nous avons la possibilité de contribuer à cet idéal des débuts d’Internet, en faisant en sorte que tous les sites sur lesquels nous travaillons soient accessibles à tous. Voici quelques conseils, si jamais vous décidez de ne faire aucun compromis.

Ne faites pas confiance à Google Analytics

Une erreur, qui est souvent faite quand on parle de performance, est de partir des statistiques données par Google Analytics (ou toute autre solution de tracking) pour se faire une idée des profils d’utilisateurs qui accèdent à votre site. L’idée de départ est simple, et paraît sensée : on regarde quelles versions de navigateurs et quels terminaux utilisent nos visiteurs, et ensuite on adapte nos tests de performances en fonction de ces données.

Le problème avec cette approche est qu’elle introduit un biais de confirmation : si votre site est inutilisable sur certains téléphones, alors il est normal que vous ne les retrouviez pas dans vos statistiques d’utilisation, puisque les visiteurs ayant ces téléphones ne risquent pas de revenir. On se retrouve rapidement dans un cercle vicieux : on abandonne le support des configurations les plus vieilles, et, au fur et à mesure que le temps passe, on se retrouve à ne supporter que des configurations récentes, tout en se confortant dans l’idée que nos décisions sont pilotées par nos données. Cet article illustre bien ce qu’on peut gagner à ne pas se contenter d’une lecture rapide de ses données d’utilisation.

Pour être réellement inclusif, il ne faut pas se concentrer sur les configurations les plus courantes, mais plutôt sur les plus vieilles et les plus lentes. Ce qui nous amène au deuxième conseil.

Achetez-vous un smartphone à moins de 100 euros

Rien ne remplace les tests en conditions réelles. Personnellement j’utilise un Galaxy S4 mini, qui ne peut plus recevoir de mise à jour Android. Encore un peu trop puissant à mon goût, mais assez vieux pour faire ramer Twitter, ou tous les sites qui abusent un peu trop de JavaScript. Pour vraiment développer de l’empathie pour vos utilisateurs, je vous conseille d’utiliser votre smartphone de test, non seulement sur votre site, mais aussi pour votre utilisation personnelle. Une semaine passée à naviguer sur internet avec des téléphones de ce genre suffit à voir les sites que vous visitez régulièrement d’un œil nouveau.

N’utilisez pas [framework js] par défaut

Récemment, j’ai eu envie de compiler quelques recettes de ma grand-mère pour en garder une trace. Sans vraiment réfléchir, et ne sachant pas exactement quelle forme allait prendre le site, j’ai utilisé create-react-app, qui permet en quelques secondes de se créer un projet React pré-configuré, et prêt à être déployé. J’ai maintenant une page internet qui pèse 127Ko (dont 125Ko de JavaScript), et qui ne fonctionne pas sans JavaScript, alors qu’une simple page HTML et un peu de CSS donneraient le même résultat.

Cet exemple est un peu extrême, et j’aurais certainement fait autrement dans un cadre professionnel, mais j’ai le sentiment qu’il dénote une tendance de ces dernière années à utiliser un framework JavaScript par défaut, dès lors qu’on a un minimum d’interactivité sur une page. Cet article montre comment Netflix a réussi à améliorer les performances de leur page d’accueil en remplaçant React par du JavaScript « vanilla ».

Offline-first is the new mobile-first

Si vous développiez des sites internet dans les années 2000, vous attendiez certainement comme moi cet horizon proche où tout le monde aurait des écrans larges et haute définition pour pouvoir enfin proposer des designs créatifs qui fonctionnent pour tous vos utilisateurs, pour finalement voir l’essor des smartphones et des écrans de toutes les tailles, qui a mené au responsive design.

De la même manière, nous attendions tous que tout le monde ait accès à la fibre, et à une connexion haut débit, pour naviguer sur Internet. Aujourd’hui, force est de constater que la fibre ne s’est pas répandue aussi vite qu’on l’espérait, au qu’au contraire, le fait de pouvoir avoir accès à Internet avec seulement un abonnement téléphonique fait qu’un nombre croissant de personnes n’accèdent à internet que via une connexion 3G, voire Edge, selon la région où elles habitent.

La plupart d’entre nous connaît cet agacement d’utiliser un site internet qui fonctionne mal, lorsqu’on est en déplacement dans le train ou le métro, sur une connexion intermittente, seulement cette situation exceptionnelle pour nous est l’expérience par défaut d’internet pour certain·e·s. Ça n’est pas très important quand ça nous empêche d’accéder à Twitter pendant une heure ou deux, mais ça peut devenir problématique quand on ne peut plus accéder au site de sa banque, acheter des billets de train ou demander un remboursement de sa mutuelle. En développant des sites qui nécessitent une connexion 4G stable pour fonctionner, nous créons des citoyens de seconde zone sur Internet.

Une affaire d’équipe

Pour maintenir un certain niveau de qualité vis-à-vis des performances sur un projet, il est important que toutes les parties prenantes y soient sensibilisées. Cela inclut les développeur·se·s, mais aussi les chef·fe·s de projet, les designer·euse·s, l’équipe marketing, et toutes les personnes qui participent au développement du projet. Il est également important de mesurer l’impact sur les performances des nouveaux développements. Cela peut passer par de l’automatisation, par exemple l‘intégration d’outils d’audit dans la plateforme d’intégration continue, mais ce n’est pas une nécessité. Les développeur·euse·s ont souvent tendance à se focaliser sur la technique, alors qu’il est ici question de culture, de la vision que nous avons de notre métier. À partir du moment où vous et votre équipe pensez les performances comme un impératif, alors peu importe comment vous le mettez en place, ce sera fait. À l’inverse, si vous êtes la seule personne de votre équipe à vous en soucier, peu importe les outils que vous mettrez en place, ça aura tendance à passer à la trappe. Ça peut paraître évident, mais j’ai mis longtemps à comprendre comment avoir un impact global et sur le long terme, et il se trouve que ce n’est pas en codant mais en discutant qu’on obtient les meilleurs résultats.

2 commentaires sur cet article

  1. m

    mulk, le vendredi 13 décembre 2019 à 07:40

    Excellent article! En tant que développeurs, nous sommes trop souvent soumis (consciemment ou pas) à des tendances techniques, utilisation du dernier framework à la mode etc…
    On en oublie parfois le but et les objectifs. J’en ai l’exemple parfait avec mon taf actuel.
    J’ai été engagé par une société pour reprendre et gérer leur site réalisé par une grosse boîte de dev. « Long story short »:
    – d’abords développé avec un MEAN stack.. parce-que, euh, parce-que
    – l’appel d’offre spécifiait un back en Drupal: branlebas chez les dév. Mise en place d’un Drupal découplé avec Angular en front
    – j’arrive le 1e jour: la cata
    Un site bourré de bug, une bonne partie de fonctionnalités du cahier des charges, absentes, 1 an de dev, plusieurs équipes… un gros merdier. ET des performances à la ramasse (10 Mo à charger pour la page d’accueil, des requêtes prenants 80% de la RAM du serveur, etc…) et une dette technique de débile (codé avec le cul)
    J’ai pas mal hésité, me disant que leur choix techniques avaient peut-être du sens. J’ai demandé des explications et tout ce que j’ai réçu était un mélange de « c’est comme ça qu’on fait les sites de nos jours » « Avec angular on vous a réalisé une rolls »… hum… une rolls avec un moteir de Lada qui bouffe 25 litre au 100 et qu’on doit faire réparer toute les semaines?
    Bref, j’ai tout remonté from scratch en 2 mois, seul, sous Drupal 8 sans techno/frameworks « tendance » (version « old school ».. hum).

    Résultat: perf de malade (merci le cache de Drupal/Twig), maintenance easy.

    Conclusion: utilisez une techno en fonction de REELS besoins.

  2. N

    Nico, le vendredi 13 décembre 2019 à 11:11

    @mulk : mêmes expériences pour moi y a qq années. Perfs catastrophiques sur une page critique avec une archi base de données lamentable et supra-lente.

    Finalement, une cron qui crachait un pauvre fragment statique a résolu le souci. Difficile de battre le statique en matière de vitesse :D

Laisser un commentaire

Les commentaires sont modérés manuellement. Merci de respecter : la personne qui a écrit l'article, les autres participant(e)s à la discussion, et la langue française. Vous pouvez suivre les réponses par flux RSS.