Cet article est une transcription de ma conférence sur les Budgets de Performance tenue lors de l’événement We Love Speed (Bordeaux le 9 octobre 2018).
[ Slides ]
Je m’appelle Damien Jubeau je suis président et cofondateur de la Startup Dareboost (basée à Rennes) qui offre un Software as a Service dédié à la gestion de la performance web front-end. C’est une solution complète qui va du test à la surveillance de pages comme de parcours utilisateurs et qui offre tous les outils aux équipes pour collaborer sur la performance.
Je suis ici aujourd’hui pour vous parler des budget de performance, une méthode pour mettre vos sites web au régime
Je vais commencer avec une anecdote, sur le jeu Doom. En 2016 le poids moyen d’une page web avait atteint la taille de ce jeu vidéo, complet, du début des années 90, à savoir 2.4 Mo. Doom c’est des heures de jeu, un moteur de rendu, des textures des effets sonores, etc.
« Nous avons fait le web à notre image, obèse. »
Cette citation de Jason Grigsby résume bien la situation le web qui a une tendance à l’obésité. Et quand on y regarde de plus près ce n’est pas vraiment étonnant.
En effet un site web c’est quelque chose de complexe, il y a énormément de contraintes qui viennent de nombreux acteurs. Par exemple au niveau organisationnel vous allez avoir des contraintes financières, qui vont forcément limiter le champ des possibles. Un autre point important, c’est le modèle de revenu qui est associé au site web. Je pense par exemple aux site presse et médias qui ont un modèle de monétisation via la publicité. J’imagine que la plupart d’entre vous sont au fait des challenges qui sont inhérents un modèle lié à la publicité pour la performance web… Il y a bien d’autres contraintes organisationnelles qui vont s’ajouter, comme la direction artistique ou encore un management plus ou moins politique avec des prises de décisions qui seront complexifiées à divers degrés.
Au niveau opérationnel, on peut parler d’entropie logiciel, avec une tendance à la dette technique. C’est un système qui va vivre, évoluer, et donc l’avoir tendance à se complexifier voire se dégrader. Vous pouvez par dessus cela aussi de faire face à des limites de compétences dans les équipes. Il y a enfin tout ce qui va concerner les aléas : devoir faire face à des pics de charge, à des problématiques réseau et de nombreuses dépendances à des services externes qui vont eux aussi connaître leurs lots de défaillance.
En bref, pour résumer tout cela : un site web c’est un système complexe, faisant intervenir de nombreuses parties-prenantes, apportant toutes leurs lots de contraintes. Un système qui va évoluer et avoir tendance à se dégrader si on ne met en place les garde-fous nécessaires.
Face à cela, on a la nécessité d’avoir des pages rapide. J’aime beaucoup cette citation de Larry Page, qui nous invite à définir la vitesse comme la première fonctionnalités du produit. Pourquoi considérer la nécessité de vitesse comme prépondérante ? Parce que vos visiteurs, quand ils viennent sur vos pages, ont un besoin. Ce besoin peut-être de trouver une information, d’acheter un produit, etc. Dans tous les cas vos visiteurs ont une capacité à attendre qui va être associé à ce besoin, qui va correspondre à la valeur attendue, à la valeur espérée. Il est donc impératif de répondre à ce besoin dans le temps qui vous est imparti. Mettre la vitesse en fonctionnalités numéro 1 de votre produit c’est garantir que vous répondiez suffisamment rapidement à ce besoin, que vous offrez la valeur dans le temps qui vous est consacré. Sans respect de cette nécessité de vitesse : le reste de votre travail n’aura pas de sens. Toute autre fonctionnalité deviendrait futile si la promesse n’est pas tenue dans un délai acceptable pour le visiteur.
Comment fait-on pour éviter que votre site web ne se dégrade, comment éviter cette tendance au dérapement et à l’obésité ? Comment garantir que la vitesse soit au cœur de vos préoccupations ? Avec les budgets de performance.
Exemples de budgets de performance
Commençons avec un exemple de budget, peut-être le plus simple : “Je veux que mon site soit rapide”. C’est un budget qu’un décideur pourrait facilement exprimer, que le commanditaire d’un site web pourrait exprimer auprès d’un prestataire.
Ce budget n’est pas précis, n’est pas objectif. Mais il permet d’orienter le projet, de placer un enjeu, une attente, sur la performance. C’est donc une première orientation qui est donnée et qui ne demande qu’à être déclinée.
Si l’on veut rentrer sur quelque chose d’un peu plus précis, avec un autre exemple de budget performance : “le poids des pages ne doit pas dépasser 1Mo”. C’est un exemple de budget qui qui devrait me permettre de communiquer avec un designer par exemple.
Je vais pouvoir comprendre en faisant ma maquette, qu’il est inconcevable de mettre 18 carrousels, 13 police de caractère et 3 vidéos HD en arrière plan.
Ce budget est exprimé sur quelque chose qu’on peut assez facilement anticiper, il va me permettre de poser un cadre pour éviter des erreurs qui seraient irrattrapables en termes de performance par la suite.
Enfin un 3e exemple de budget de performance avec quelque chose qui va être encore plus précis et concerner les plus avertis : “nos page doivent avoir un speed index inférieur à 2000 sur mobile avec une connexion 3G.
Le Speed Index, dont vous a parlé Jean-Pierre ce matin, est un indicateur qu’on va pouvoir obtenir avec une mesure synthétique. On est aussi ici sur un contexte de mesure précis. On va pouvoir se confronter à ce budget tout au long de la vie du projet web, et s’assurer de déclencher des investigations et des corrections en cas de non respect.
Comment utiliser au quotidien les budgets de performances
Voyons justement comment utiliser au quotidien les budgets de performances. Voyons comment ils vont jouer leur rôle de garde-fous, comment ils vont nous servir lors de la prise de décision.
Imaginons une page d’accueil qui fait 800 ko, que je me suis fixé un budget de 1 Mo. Mon département marketing me demande de mettre en place un carrousel sur la page d’accueil pour mettre en avant davantage de produits. La motivation derrière c’est que les produits mis en avant sur la page d’accueil sont davantage achetés, et génèrent donc davantage de revenus. Problème : ce carrousel est trop lourd et je ne respecte pas mon budget. Alors comment faire dans ce cas-là ?
Je vais tout d’abord pouvoir envisager d’optimiser cette nouvelle fonctionnalité. Pour mon carrousel je vais pouvoir optimiser les images, minifier le JavaScript, m’assurer qu’il soit compressé, etc.
Avec un peu de chance cela va me permettre de respecter mon budget et tout va bien. Dans le cas contraire, il me reste une autre solution, je vais pouvoir m’intéresser à ce qui existe déjà sur ma page, faire un coup de ménage. Par exemple, je vais pouvoir aller supprimer la solution d‘A/B testing que l’on n’utilise plus depuis 6 mois…
Après cela, avec un peu de chance je respecte mon budget et tout va pour le mieux.
Et si ce n’est toujours pas le cas ? Il va alors falloir que je m’interroge sur ce je fais, que je me pose à nouveau la question de la valeur de cette évolution.
Nous n’arrivons pas à respecter notre budget, la page va être plus lourde / lente que ce que nous autorisons. Est-ce que rajouter ce carrousel est vraiment une bonne idée ? On va s’interroger à nouveau sur la valeur de ce qu’on est en train de faire et si cette valeur n’est pas suffisante, alors on n’a aucun intérêt à mettre en place cette évolution, c’est une erreur. Si je constate qu’au final ce carrousel ne va pas permettre de générer des revenus supplémentaires ou pas suffisamment (à ce sujet: shouldiuseacarousel.com), la seule solution est d’abandonner cette nouvelle fonctionnalité.
À l’inverse si je suis convaincu de l’opportunité derrière cette évolution, que ce soit de la valeur apportée à mes visiteurs ou à mon activité, je vais poursuivre et mettre en place cette fonctionnalité. Pour autant l’idée n’est pas d’abandonner mon budget : je vais le faire évoluer de façon à ce qu’il puisse à nouveau m’être utile à la la prochaine itération, pour la prochaine évolution.
En effet le budget de performance ici m’a permis de m’interroger sur la valeur de ce que je faisais, d’optimiser le nouveau comme l’existant. C’est vraiment un outil qui m’a permis de communiquer, d’échanger sur le pourquoi d’une fonctionnalité et de communiquer sur ses impacts sur la performance. Et donc de m’assurer que la nécessité de vitesse obtient bien l’attention qu’elle mérite.
Comment choisit-on un budget ?
La première chose à garder en tête, c’est qu’on ne peut améliorer que ce que l’on mesure. Il faudra contrôler vos performances et les confronter à vos budgets. Attention aux choix des indicateurs, je vous renvoie à la conférence de Jean-Pierre à sujet, notamment à la possibilité d’utiliser des User Timing pour avoir une vision de la performance au plus proche de votre métier.
Au-delà de ça : toutes les pages ne sont pas équivalentes. Vous n’avez probablement pas les même budget de performance que Netflix ou que Facebook. Vous êtes sur un marché identifié, vous avez des concurrents, et vous avez donc des particularités que vous allez devoir prendre en compte pour fixer vos budgets. Autre point important : toutes vos pages ne sont pas équivalentes. Gardez en tête que certaines pages ont des enjeux plus marqués que d’autres. Focalisez vos efforts là où il y a du business à aller chercher. Cela vous permettra de garder une approche ROIste, nécessaire à la pérennité de l’approche.
La première méthode que j’apprécie pour fixer un budget c’est de regarder ce qui se passe chez vos concurrents, de se positionner par rapport à ces derniers.
Benchmarkez vos concurrents avec du monitoring synthétique, et si vous êtes le mauvais élève de la classe, vous cherchez à rattrapper votre retard.
A l’inverse, si vous êtes déjà dans le haut du tableau, votre objectif sera peut être de vous créer un avantage concurrentiel à part entière sur la rapidité. Il y a des success stories comme Capitaine Train, depuis racheté par The Trainline, qui de mémoire ont fait grand bruit en offrant un service bien plus rapide que l’acteur historique en place.
Une autre façon d’aborder le choix d’un budget peut être l’expérimentation, Stéphane vous en a parlé plus tôt. Un bon moyen de savoir quel budget fixer, c’est de mesurer combien cela nous coûte de l’enfreindre ! Plus généralement, c’est un bon moyen pour rappeler et objectiver les enjeux de la performance, en vous appuyant ainsi sur de la data qui est propre à votre activité et à votre environnement.
Si votre objectif est d’améliorer les performances de votre site existant pour avoir un effet « wahou » de la part de vos visiteurs ou de parties-prenantes du projet, visez quelque chose de significativement plus rapide. En effet la règle des 20% nous indique qu’une accélération du site ne sera perçue par les utilisateurs que si leur navigation est au moins 20% plus rapide qu’auparavant. Cela ne veut pas dire qu’avec des optimisations plus modérés vous ne verrez pas d’améliorations dans vos KPIs, mais le changement ne sera pas perçu, les visiteurs ne détecteront pas les performances accrues. Visez donc une release avec une accélération marquée pour espérer obtenir spontanément des feedbacks positifs.
Stéphanie vous a parlé de la performance par le prisme de l’UX, c’est un bon moyen de fixer certains budgets en se basant sur les grands seuils de la perception utilisateur.
Ma dernière approche pour fixer des budgets serait de rappeler que certains nous sont imposés. Je pense par exemple au budget de crawl de Google. Parmi les préoccupations fortes des métiers du SEO, c’est le temps que Google accorde à un site (selon l’importance accordée) pour explorer les pages web de ce dernier. Plus vous avez de pages, plus c’est un sujet critique. Si les bots de Google ne parviennent pas à visiter toutes vos pages dans le temps imparti, vous risquez de voir certaines de vos pages indexées tardivement, ou peu mises à jour.
Pour contrer cela, vous en viendrez probablement à vouloir réduire votre TTFB et ainsi accélérer l’exploration de vos pages par les bots.
Une autre forme de budget qui nous est imposé, quand on s’intéresse à l’optimisation du chemin critique cette fois. Si vous souhaitez avoir un premier affichage très rapide de votre page, il vous faudra vous assurer que les données nécessaires puissent transiter sur un seul aller-retour sur le réseau.
Sur du TCP, du fait du « slow start », c’est donc une fenêtre de tir de 14ko environ dont vous pourrez bénéficier, pas plus.
Culture de la performance : emporter l’adhésion sur vos budgets
Les budgets sont des gardes-fous, mais aussi un outil de communication essentiel. Je l’ai rapidement illustré avec l’exemple du commanditaire d’un site web qui exprime un besoin de rapidité, qui est par la suite décliné selon les interlocuteurs et les phases du projet.
C’est un outil d’échange qui nous permettra aussi de faciliter les compromis, comme nous l’évoquions avec notre hypothèse de l’ajout d’un carrousel qui nous faisait dépasser le budget.
Ainsi pour que cet outil fonctionne, il est nécessaire qu’il emporte l’adhésion des parties prenantes du projet. Il est donc utile de travailler sur cette approche de manière collective plutôt que d’essayer de les imposer. Allez y par étape, n’essayez pas de fixer trop de seuils sur trop d’indicateurs. Il est important de rester sur quelque chose qui sera actionnable et sur lequel les équipes pourront réagir rapidement.
Parmi les exemples les plus affirmés de l’adoption de budgets chez nos clients, il y a ceux par exemple qui ont pris en compte les objectifs de performance web comme critère dans l’intéressement des équipes ou des primes individuelles.
Pour conclure, l’adoption de budgets de performance dans vos projets vous permettra de replacer la performance à place qu’elle mérite, d’une voir une fonctionnalité à part entière. Non seulement, le process mis en place vous permettra de vous assurer qu’une nouvelle fonctionnalité ne passera pas au travers du filet des optimisations nécessaires, mais vous aurez aussi systématisé le fait de vous interroger sur l’existant pour l’épurer régulièrement du superflus.
Enfin, cet outil vous permettra de mieux communiquer et d’ouvrir la discussion sur les compromis entre la valeur des évolutions mises en places et leurs impacts sur la vitesse de chargement du site web.