Ce vendredi j’ai eu le plaisir d’intervenir au SEO CAMP Day de Lille sur le sujet de la performance web et comment avoir une approche qui marche. Je vous partage ici mes slides ainsi qu’une retranscription de mon speech. Un lien vers un Periscope est en bas.
Importance de la performance web
[Diapositive 1] Bonjour à toutes et à tous, content d’être là et content que vous soyez venus pour passer un peu de temps ensemble. On va parler pendant quelques minutes du sujet de la performance web et plus spécialement je vais vous partager une approche qui a fonctionné dans des contextes de mes clients et j’espère qu’elle vous sera utile dans votre quotidien. Permettez moi d’abord de vous donner quelques constats sur le sujet.
[Diapositive 2-3] A mes yeux, un premier constat c’est que le web appartient à ceux qui l’utilisent et non pas à ceux qui l’éditent. C’est les utilisateurs qui y passent leur temps à y accomplir leurs objectifs (recherche d’information, achat, échange et divertissement). On doit être bienveillants envers eux car la performance impacte d’une manière drastique l’expérience utilisateur.
[Diapositive 4-5] Une mauvaise performance génère du stress et c’est pas anodin car selon HTTPArchive 50% des sites mettent 13secondes à se charger en 2018..Et la tendance est loin d’être inversée car depuis 2010 la taille des pages web à triplé sur Desktop et a octuplé sur Mobile.
[Diapositive 6] Une mauvaise performance c’est aussi un facteur d’exclusion. Des personnes dans le monde avec des connexions limitées, des terminaux d’entrées de gamme (CPU, mémoire) et des forfait internet très chers ou réduits peuvent être carrément privées d’une partie du web. Nous avons tous un rôle à jouer pour rendre le web le plus ouvert possible en traitant le sujet de la performance. Le site https://whatdoesmysitecost.com permet d’avoir une idée sur des disparités intéressantes. Prenons un exemple, le site https://www.lemonde.fr, y accéder depuis la Mauritanie coûte l’équivalent de 1.16% du Revenu par tête journalier contre 0.03% en France.
[Diapositive 7-8] Pour l’anecdote, quand l’Ouragan Florence a eu lieu fin Août 2018 en Amérique du Nord, La Public National Radio (PNR) a publié une version text-only de son site internet afin d’y faciliter l’accès pour les victimes qui sont dans un contexte difficile. Une bonne manière d’être présent peu importe le contexte de vos clients. Je vous invite à lire l’article récent de Tim Kadlec The Ethics of Web Performance.
[Diapositive 9] Et vous savez quoi ? Il n’y a pas que les utilisateurs qui subissent ça.. les moteurs de recherche aussi. Google qui introduit la vitesse de chargement comme facteur de positionnement en disant que les sites rapides seront mieux appréciés. Vous l’avez compris ça veut dire moins coûteux à crawler.
[Diapositive 10] Et d’une manière plus générale, l’impact de la performance, je le vois sur plein de métriques business ou autres tel que la satisfaction clients, notoriété de la marque, chiffre d’affaire/session, le coût de l’infrastructure, le nb de sessions, le bounce rate, la fréquence de crawl et le forfait internet de vos utilisateurs..
[Diapositive 11] Vous êtes d’accord avec ça vous ? Oui ? Et bien on est tous d’accord sur l’importance de la performance mais les entreprises ont une mauvaise compréhension du sujet de la performance web. Vous êtes d’accord aussi ?
[Diapositive 12-13] Mauvaise compréhension veut dire manque de sensibilité, confusion sur comment faire et à quel moment..et on voit tous les jours des patterns qui le confirment. Comme par exemple, ne pas se mettre à la place des clients ou encore prioriser les fonctionnalités au détriment de la performance ou ce que j’appelle développer rapidement un site lent. Un autre pattern classique c’est de traiter la performance comme un sujet ponctuel un peu comme la résolution d’un bug, on est lent on fait un audit et on corrige… deux mois après on retombe dessus. Et bien la performance ce n’est pas un bug, la performance c’est la fonctionnalité.
Attention, je ne suis pas entrain de dire que les développeurs sont mauvais, ou que les chef de projets sont nuls. Ils se sont plutôt retrouvés dans des situation où c’est difficile de faire mieux. J’ai jamais vu une personne qui vient le matin avec un objectif de développer un site lent..C’est plutôt le business modèle dans lequel ils vivent les empêchent de créer des choses performantes.
La performance est un sujet culturel
[Diapositive 14] Vous voyez ? C’est pourquoi, la performance à mes yeux c’est un sujet culturel. Les entreprises qui affichent leurs valeurs, ils mettent souvent ‘satisfaction client’, ‘sens de la performance’, ‘bienveillance’..Vous ne pensez pas que la performance web en fait clairement partie ? En effet, pour être cohérent, plusieurs couches de l’entreprise doivent être sensibilisées au sujet de la performance web. De la vision stratégique, du management, de la maturité technique, dans les choix des frameworks, du design / UI / UX et des outils et culture de la qualité.
[Diapositive 16] Pour y arriver sur le terrain, il faut avoir une approche qui marche, et c’est ce que je vais essayer de vous partager maintenant issue d’histoires vraies que j’ai pu vivre dans plusieurs projets avec mes clients.
Approche organisationnelle pour la performance web
[Diapositive 17] Pour commencer on va constituer une équipe de performance dédiée qui a une durée de vie (3 mois c’est indicatif et ça dépendra de la taille de l’entreprise et le nombre des projets). Cette équipe a comme objectifs :
- Faire le point et savoir où est ce qu’on se situe;
- Éduquer et insuffler une culture de performance;
- Définir avec les équipes les process
- Mettre en place des outils de performance
- Définir les KPI et métriques de performance qu’on va suivre
A terme, l’équipe sera dissoute et la performance devient un critère d’acceptance et de qualité dans chaque équipe de l’entreprise.
En parlant d’éducation, plusieurs actions sont possibles :
- Se donner le temps pour apprendre (Livres, conférences, articles)
- Se donner le temps pour tester des choses (POCs, techniques)
- S’inspirer des autres réussites (https://wpostats.com/ regroupe plusieurs retours d’expérience sur l’optimisation de la performance web)
Les métriques et KPI de performance web
[Diapositive 20]Parlons maintenant des métriques de performance. Pour travailler la performance on a besoin de métriques pour mesurer et suivre ça dans le temps. Il y’a une panoplie de KPI et j’i essayé de les classer en 4 catégories. Les métriques quantitatives comme le nombre de requêtes la taille de la page, les scores des outils, TTFB…etc. C’est intéressant de les suivre mais leur grand bémol c’est qu’ils ne reflètent pas l’expérience de l’utilisateur. On peut bien avoir un site qui fait 45 requêtes et une taille de 1Mb offrant une meilleure performance perçue qu’un autre avec 30 requêtes et 500Kb.
En deuxième catégorie on retrouve les métriques visuelles, celles là font focus sur une partie de l’expérience utilisateur.
- FCP (First Contentful Paint) : donne une idée sur temps pris pour afficher le premier rendu de la page.
- FMP (First Meaningful paint) : A quel moment le premier pixel du contenu commence a être affiché. On exclut tout ce qui est navigation, éléments du template de la page, la sidebar…etc
- Speed Index : Donne uee idée sur la vitesse avec laquelle le rendu se propage sur le viewport.
- Visually complete
Ces métriques sont intéressantes à mesurer et à suivre car elles nous projettent dans l’aspect visuel de l’expérience utilisateur. Les utilisateurs vont certes interagir avec l’interface web et avec ces deux catégories on est pas capable de dire si l’interface va répondre rapidement. C’est pourquoi il faut une troisième catégorie : Les métriques d’interactivité.
- Time To Interactive : A quel moment la page est prête à recevoir les interactions de l’utilisateur
- First Input Delay : Le délai entre le moment où l’utilisateur réagit pour la première fois avec la page et le moment où le navigateur est prêt pour y répondre
- First CPU Idle : Quand la page est devenue interactive à minima
Des métriques intéressantes pour refléter l’expérience de l’utilisateur malgré que certaines d’entre elles pourraient être truquées et qu’elles restent génériques.
Les métriques customs
La dernière catégorie de métrique permet de mesurer la vitesse de chargement de ce qui compte le plus à votre business : Les customs metrics.
[Diapositive 21] Ou comment mesure l’affichage du haut (hero element) ! Exemple pour un site e-commerce, on va mesurer la vitesse de chargement de l’image produit Time To Hero Image. Pour un site média, Time To Hero Text..etc.
[Diapositive 23] Un fois que vous avez compris les métriques, il faut en choisir quelques unes pour pourvoir mesurer, travailler dessus et suivre dans le temps. Pensez également à corréler les métriques de performances avec les métriques business. Exemple ici on voit une augmentation du bounce rate quand le start render (ou FCP/FMP) dépasse les 2 secondes.
Outils de performance web
[Diapositive 24-26] Maintenant vous êtes prêts coté métriques mais il vous faudra des tools avec quoi vous allez mesurer. On distingue les outils synthétiques qui permettent de tester chez nous sur un environnement maîtrisé. ça permet de tester d’une manière objective, déboguer en développement et comparer aussi dans le temps. L’inconvénient de ces outils c’est, vous l’avez compris, qu’ils ne représentent pas l’expérience vécue par nos utilisaturs. On va donc les compléter avec les outils terrains ou RUM (Real User Monitoring).
Les outils RUM sont chez les utilisateurs. Ils permettent de voir comment notre site se comporte dans la vraie vie face à des contextes différents (localisation, connexion internet, latence et type et puissance du support).
Il faut s’équiper des deux ensemble, je vais vous montrer un peu plus tard de quelle façon. En synthétique il y’a Webpagetest, Google Lighthouse, Gtmetrix, la console Google Chrome parmi les meilleurs outils. En RUM, on a Chrome User Experience Report (CruX), Google Analytics.. Et entre les deux, Google Speed Insight, Speedcurve, Pingdomtools..etc. Pour a suite, on va utiliser Google Lighthouse et CrUX.
Budget de performance
[Diapositive 27-28]Pour travailler la performance d’une manière pérenne, il va falloir fixer notre seuil de qualité ou ce qu’on appelle budget de performance. Il s’agit de dire par exemple on ne se permet pas d’avoir plus que 600kb en taille, que notre FMP ne doit pas dépasser 2.3s et que notre score Lighthouse de performance soit au moins 80/100.
[Diapositive 29-30] Afin de respecter ce budget de performance, il va falloir en première étape se poser les bonnes questions en amont de chaque fonctionnalité :
- Il y’aura-t-il des appels à des APIs externes ?
- Va-t-on charger plusieurs scripts ? combien ?
- On augmente le nombre de requêtes BDD/page ?
- Cette fonctionalité rentre-t-elle dans notre budget de performance ? On serait à combien ?
Ces questions là doivent être traitées par les différents acteurs et pas seulement les personnes techniques (produit, marketing, technique..etc). Des discussions auront certainement lieu et l’objectif c’est de prioriser. Il existe plusieurs frameworks de priorisation et en voici un exemple. Distinguer l’importance de chaque contenu selon son type : Contenu core, Contenu d’amélioration ou autre.
Automatiser les tests de performance
[Diapositive 31-36] Deuxième chose, après le développement de chaque fonctionnalité on doit la tester avec notre outil synthétique pour s’assurer de notre budget de performance et apporter des ajustements au cas où. Et pour ça, on va pas s’amuser à le faire manuellement. Voici la configuration que je mets en place avec mes clients.
- Le développeur écrit du code
- Il en envoie son code sur le système de versionning (Github ou Gitlab..)
- On fait appel à la CI (ici Travis)
- La CI fait appel à Lighthouse CI
- On exécute des tests de performances sur différentes instances pour chaque typologie de page (a faire absolument pour chasser les régressions)
- Lighthouse communique les résultats. Si ok on permet au développeur de « merger » (fusionner) son code et livrer en production/préproduction sinon on empêche et on doit corriger pour que ça passe.
Ici un exemple sur Github où ça passe et donc le build est fait avec un récapitulatif : nouveau score Vs seuil demandé.
Un exemple ou ça échoue, car le score de performance est au-dessous du seuil. Qu’en pensez vous ?
Vous vous rappelez des métriques custom ? Et bien c’est possible aussi de les intégrer dans ce workflow. Je vous invite à lire mon article dans lequel je montre comment créer des audits customs avec Lighthouse. L’exemple traité dans le tutoriel c’était de tester si l’image produit de Amazon.fr s’affiche en moins de 3 secondes.
Exploiter la RUM pour valider (CrUX)
[Diapositive 37-40]Troisième chose qui reste à faire maintenant, c’est après la mise en production, on doit valider les résultat grâce aux outils RUM (CrUX dans notre cas). Google Chrome collecte, quand il a eu la permission, des métriques de performance des utilisateurs visitant un site. Grâce à ces métriques il construit une base de données accessible au public. Et c’est une mine d’or car je peux en 4 lignes savoir comparer des concurrents, suivre ça dans le temps et donc me fixer des objectifs pour les dépasser. On voit ici que 60% des visiteurs d’amazon.fr ont bénéficié d’un FCP<1s en février 2018. Ou encore, qui parmi le top 10 des e-commerce Français a évolué en performance…Etc. J’ai créé un ensemble de requêtes SQL utiles pour explorer la CrUX sur mon Github.
Pour les personnes non techniques, y’a moyen d’avoir des infos grâce à un Dashboard Google Data Studio. On voit dans cet exemple que Google offre un meilleur FCP que Bing.
[Diapositive 41] Si on récapitule un peu notre approche. On a développé du code, on l’a testé chez nous, on l’a livré à nos utilisateurs et enfin on l’a validé grâce à la RUM. Il faut garder cette approche dans le temps en itérant à chaque fois afin d’avoir de bonnes performances web dans le temps.
Si vous souhaitez des tips plus techniques sur l’optimisation de performance, vous pouvez checker mes slides de SEO Camp Day Lorraine sur mon Slideshare : Quick-wins pour accélérer son site web.
Hasni a fait un Periscope à partir de la diapositive7 que vous pouvez visionner ici : https://www.pscp.tv/HasniSEO/1lDGLMVmnaRJm
Mes prochains RDV webperf :
- Webinar 29/01/2019 : La vitesse d’un site : une nouvelle vision https://fr.semrush.com/webinars/la-vitesse-d-un-site-une-nouvelle-vision/
- Workshop pratique sur l’optimisation de la performance 17/05/2019 Genève – PerformanceWeb.ch
Consultant SEO International