Source originale du contenu
Je vous propose de découvrir une notion essentielle pour adopter une véritable culture de la performance web sur vos projets : les budgets de performance.
Ces derniers ne vont pas s’exprimer en euros, mais en secondes, en mégaoctects ou encore en nombre de fichiers !
Une notion qui mériterait d’être connue et d’être utilisée par tous les métiers du web, pour accompagner le cycle de vie des sites web et reprendre le contrôle de leur rapidité.
Le constat initial
Le web grossit. Les pages s’alourdissent, le nombre de ressources (images, scripts, css, etc) nécessaires pour afficher une page web ne cesse de croître.
Pourquoi ? Parce qu’aujourd’hui les sites web sont des applications à part entière, avec des fonctionnalités qui peuvent être très riches, et offrant de nombreux contenus multimédias.
A l’heure actuelle, si l’on considère les 1000 sites les plus visités au monde, voici le bilan dressé :
Même si vous avez à coeur la performance lors du développement initial de votre site web, ce dernier va inexorablement évoluer : nouvelles fonctionnalités, nouveaux contenus, refactoring technique, etc.
Votre site va vivre et s’enrichir : A/B Testing, moteur de recommandations, retargeting, click-to-chat, etc, sont autant de fonctionnalités qui se répandent et sont à même d’intervenir dans le cycle de vie de votre site web.
Le budget de performance est un framework, un outil qui va vous permettre de placer la performance au coeur de vos préoccupations et d’éviter toute dérive qui conduirait à ralentir votre site, car n’oublions pas, un site rapide est indispensable au succès de votre business.
La vitesse est une fonctionnalité
En 2010 Urs Hölzle a rapporté ce propos tenu par Larry Page, cofondateur de Google :
“As a product manager you should know that speed is product feature number one.”
(traduction : en tant que responsable produit, tu devrais savoir que la vitesse est la fonctionnalité numéro un du produit)
La vitesse est une philosophie chez Google, puisque considérée depuis les débuts comme une différenciation majeure.
Je vous propose de découvrir pourquoi ce propos est plein de sens, et en quoi il nous amène à la notion de budget de performance.
Vous connaissez probablement la notion de suivi de disponibilité, qui consiste à s’assurer qu’un serveur web est bien disponible (uptime monitoring), sans quoi le site n’est tout simplement pas accessible. Il ne pourra donc pas produire de chiffre d’affaires dans cette période.
Et cela peut représenter des pertes à long terme, vous risquez de vous priver à tout jamais des visiteurs qui n’auront pas pu accéder à vos pages.
La vitesse de votre site, peut être vue comme un prolongement de sa disponibilité : à quoi bon avoir un site si ce dernier met 13 minutes à se charger ? Évidemment aucun. Il est très naturel de comprendre qu’un temps d’attente extrême ne produira aucun résultat.
Et si le temps de chargement de votre page était d’une minute ? Peut-être quelques âmes patientes attendraient jusque là, mais rares seraient-elles !
La perception de l’attente est un sujet complexe, et notre patience est impactée par de nombreux paramètres. Le premier et sans doute le plus fort : la valeur que nous attendons au bout du tunnel.
Qui serait prêt à attendre 3h à la caisse d’un supermarché ? Personne.
Qui serait prêt à attendre 3h pour la sortie du dernier smartphone en vogue ? Ils sont nombreux !
Mais attention, tout le monde est loin d’être prêt à cela : notre perception de la valeur nous est personnelle.
Reprenons les courageux qui patientent dans la file pendant 3h. Seraient-ils prêts à la même chose par une température de 45° ? ou bien sous une tempête de neige ? Sans doute pas : notre capacité à attendre est contextuelle !
La difficulté qui se présente à tout éditeur de site web, c’est de devoir faire abstraction de son propre contexte, pour prendre en compte, non pas sa propre expérience, mais bien la multitude de profils qui figure parmi ses visiteurs.
Alors que l’attente effective d’un internaute sur votre page pourra être impactée par sa localisation (cf les effets de la latence), son accès Internet, son périphérique ou encore son navigateur web, la perception de cette attente pourra être impactée par ses habitudes de navigation, son expérience récente (le site précédemment visité était-il très lent ? très rapide ?), ses préjugés sur votre marque ou encore tout simplement son humeur !
Pour chaque utilisateur, une fonctionnalité X ou Y aura une valeur perçue différente.
Toute fonctionnalité aura un impact technique sur votre site, et peut donc jouer sur l’attente à laquelle vous exposez un utilisateur.
Si, comme l’évoque Larry Page, vous pensez à la vitesse comme la fonctionnalité principale de votre produit, vous aurez au coeur de vos préoccupations ces différents éléments.
Une fonctionnalité n’a de sens pour un visiteur que si la valeur ajoutée apportée compense l’attente provoquée.
La notion de budget de performance va répondre à ce problème : non pas en vous imposant d’avoir un site rapide, mais en vous permettant de considérer chaque fonctionnalité comme devant respecter une contrainte de vitesse. Vous serez donc amené à faire les arbitrages nécessaires entre la valeur apportée par une fonctionnalité et ses impacts sur la vitesse.
Quels indicateurs utiliser pour les budgets de performance ?
La notion de budget n’est en soit pas complexe, et vous en comprendrez très simplement ces exemples :
- “Notre page d’accueil doit faire moins d’1Mo”
- “Sur mobile, en 3G, toutes nos pages doivent s’afficher en moins de 3 secondes”
- “Le serveur web doit répondre en moins de 200ms”
Comme nous l’évoquions, c’est un cadre que l’on va s’imposer de respecter, d’où la notion de “budget” : vous ne pouvez pas dépenser plus de X secondes, ou plus de Y Mo, etc.
Ce cadre peut-être plus ou moins précis, et les seuils que l’on va y apporter peuvent être de natures très différentes.
Le premier pas est probablement d’intégrer la notions de performance très en amont de vos projets, dès les premières expressions de besoins. J’apprécie énormément ce propos de Brad Frost à ce sujet :
Statements of work, project proposals and design briefs should explicitly and repeatedly call out performance as a primary goal. “The goal of this project is to create a stunning, flexible, lightning-fast experience…”
(Les cahiers des charges, réponses à appels d’offres, et briefs de conception devraient explicitement et de manière répétée mentionner la performance comme objectif principal. “Le but de ce projet est de créer une expérience à couper le souffle, souple, rapide comme l’éclair …”)
On s’assure ainsi de ne jamais oublier ce critère et d’en faire un point de vigilance majeur. C’est nécessaire à toutes les étapes de votre projet.
Plus la prise en compte de la performance sera tardive, plus les efforts à mettre en oeuvre seront importants.
Pour vous permettre d’exprimer vos budgets de performance, Tim Kaldec a proposé un découpage très intéressant des métriques disponibles, que je vous propose de découvrir ici :
Milestone timings (jalons temporels)
Exemples : Temps de réponse serveur; Temps de chargement total; Temps avant début de l’affichage;
Ces mesures ont l’avantage d’être faciles à suivre dans le temps, l’idéal pour mettre en place un cadre à respecter pour l’équipe technique. Attention cependant : le chargement d’une page ne se résume pas à un instant T, heureusement, le speedindex va venir en renfort.
SpeedIndex (indice de performance)
Cet indice est largement reconnu par les experts en performance web, car il retranscrit comment la page va se charger avec une seule valeur, d’un point de vue utilisateur.
Il a donc mérité pour Tim une catégorie dédiée, et ce n’est pas un mal, même si j’aurais tendance à y ajouter le Time To Interact (qui fait partie de la catégorie précédente), car l’affichage de la page doit être complété de son interactivité pour que l’expérience utilisateur soit vraiment au rendez-vous.
Si vous souhaitez en savoir plus sur le speedindex, vous trouverez dans cet article des explications ainsi que sur 2 autres métriques liées au rendu visuel.
Quantity based metrics (Mesures basées sur la quantité)
Exemples : Nombre de requêtes; Poids total de la page; Poids total des images
Nous avons ici des mesures sans lien direct de cause à effet sur l’expérience utilisateur. Cependant, l’énorme avantage est que ce sont des valeurs que l’on anticipe beaucoup mieux que l’impact sur l’expérience utilisateur.
Comme nous l’indique Tim, il est bien plus facile de comprendre que l’ajout d’un script va augmenter le poids de la page, que d’anticiper l’impact de ce script sur le speedindex.
Un autre exemple, très en amont dans la chaîne de conception, que j’apprécie beaucoup, est apporté par Daniel Mall : lors du maquette graphique, limiter le nombre de polices de caractères qu’il est possible d’utiliser ! C’est un exemple typique de la nécessité d’intégrer des budgets au plus tôt : la maquette proposée par votre graphiste peut être esthétiquement superbe, mais vous conduire à des performances nécessairement désastreuses;
Rule based metrics (mesures basées sur des règles)
Exemples : score PageSpeed; score YSlow; score DareBoost
Plusieurs outils existent sur le marché pour vous permettre vérifier sur une pages web le respect des bonnes pratiques qui favorisent la rapidité. Ces scores résument donc la qualité technique de vos pages du point de vue de la performance (les ressources sont-elles compressées ? les images sont-elles optimisées ? etc) .
Là encore, il n’y a pas de relation directe avec l’expérience utilisateur, mais en intégrant ce type de scores dans vos budgets, vous vous assurez de détecter des régressions majeures, et de ne pas louper d’optimisation technique évidente.
Comment fixer le seuil d’un budget ?
Nous l’avons évoqué au cours des paragraphes précédents, les budgets de performance doivent être mis en place le plus tôt possible dans vos projets, et accompagner ceux-ci tout au long de leur cycle de vie.
Il faudra veiller à adapter les indicateurs utilisés en fonction des étapes et des interlocuteurs.
Mais quelles sont les méthodes pour fixer un budget ? Quelle vitesse devez-vous atteindre ? Comment choisir ces seuils qui vont accompagner vos projets et peuvent être des contraintes fortes à certaines étapes ?
Ces questions ont été l’objet de l’article Fast Enough de Tim Kaldec, qui nous rappelle notamment la règle des 20% apportée par Steven Seow : on ne perçoit une différence entre deux durées que si l’écart entre elles est supérieur à 20%.
En vous basant sur cette règle, vous pourrez donc fixer vos budgets en vous positionnant par rapport à vos concurrents, que ce soit pour être meilleur (au moins, 20% plus rapide) ou à défaut, ne pas être être perçu comme plus lent ! (au plus, 20% plus lent).
Autre méthode intéressante, toujours mentionnée dans cet article : se baser sur la perception du temps. Une réponse en moins de 100ms parait instantanée, 1 seconde est la durée pendant laquelle un internaute conserve son attention au maximum, alors qu’au bout de 10 secondes il l’aura totalement perdue.
Vos budgets peuvent également être composés pour prendre en compte les coûts pour vos visiteurs : dans de nombreux pays, les connexions mobiles sont encore limitées en bande passante, et naviguer sur des sites mobiles trop lourd est loin d’être anecdotique ! Pour en savoir plus, je vous invite à consulter cet excellent projet : http://whatdoesmysitecost.com/
Ces quelques données vous aideront, mais encore une fois, la perception de l’attente est dépendante de la valeur attendue et obtenue, c’est donc dans cette optique que vous devez concevoir vos budgets !
S’adapter aux budgets ou adapter les budgets
Lorsque vous ajoutez une nouvelle fonctionnalité ou un nouveau contenu, il n’est pas étonnant que vos budgets puissent être mis à mal. Mais votre objectif doit être de les respecter à tout prix !
Lorsqu’un budget est enfreint, vous allez devoir successivement envisager ces différentes possibilités :
- optimiser : que ce soit sur ce changement ou sur un élément déjà existant, pouvez-vous mettre en place des optimisations qui vont vous permettre de respecter à nouveau les différents budgets ?
- épurer : peut-être qu’un ancien contenu ou une ancienne fonctionnalité n’est plus nécessaire et peut être supprimé ?
- abandonner : la valeur ajoutée apportée est-elle suffisante pour justifier une violation des budgets ? Si ce n’est pas le cas, c’est peut-être tout simplement que cette nouveauté n’en vaut pas la peine
- évoluer : si aucune des actions précitées n’est envisageable, il ne vous restera pas d’autre solution que de faire évoluer les budgets de performance problématiques. Il n’est pas question de les abandonner, mais bien de les faire évoluer pour pouvoir intégrer le changement. Vous aurez ainsi un nouveau cadre à respecter à l’avenir.
Quelle que soit l’issue, le budget de performance en tant qu’outil aura fait son office : vous vous serez interrogé sur les impacts de cette évolution, et vous en aurez maîtrisé les conséquences.
J’espère que cet article vous aura convaincu de l’utilité de mettre en oeuvre les budgets de performance dans vos projets, pour que tous ensemble nous allions vers un web plus rapide !
Damien Jubeau
CEO et co-fondateur du service en ligne dareboost.com (diagnostic automatique de la performance web et surveillance quotidienne des budgets de performance)