[Vidéo et transcription de ma présentation à BrightonSEO, avril 2023]
Bonjour à tous. Je suis Aymen Loukil, consultant international en SEO et performance web. Aujourd’hui, je vais vous expliquer comment, il y a quelques années, Google Lighthouse m’a fait échouer et perdre de l’argent, pour que vous ne viviez pas la même expérience.
=> Je préfère regarder l’enregistrement.
Revenons donc à mon parcours de 2017 en conseil sur la performance web. À l’époque, j’étais un grand fan de Google Lighthouse. Voici à quoi ressemblait mon workflow en performance web : commencer avec Google Lighthouse et finir avec Google Lighthouse. Et entre ces deux étapes, on modifiait, implémentait et essayait d’optimiser les choses, n’est-ce pas ?
Donc, pour l’un de mes plus gros clients, un site e-commerce international, nous travaillions sur l’optimisation du modèle de la PLP (Product Listing Page) sur mobile. Nous avions réussi à améliorer drastiquement le score Google Lighthouse, en passant de 42 à 63, et c’était génial, vraiment, car les développeurs web adorent avoir un impact. Et en tant que consultant, mon rôle est d’aider mes clients.
J’étais donc tout excité, demandant à déployer en production : “S’il vous plaît, déployez-le. J’ai hâte de voir comment cela va se comporter en production,” n’est-ce pas ?
Alors, vous savez quoi ? Nous avons déployé. Mais nous devions attendre au moins 28 jours pour obtenir le prochain ensemble de données mensuelles du CrUX (Chrome User Experience report), afin de voir si cela avait réellement bénéficié à nos utilisateurs ou non.
Chaque deuxième mardi du mois, nous recevons les données mensuelles et pouvons analyser si nous avons vraiment apporté une amélioration. Mais, vous savez, sur un site web, en un mois, beaucoup, beaucoup de choses peuvent arriver : ajout de fonctionnalités, corrections de bugs, régressions, etc. C’est vraiment trop long pour pouvoir affirmer : “Oui, nous avons optimisé les choses pour nos utilisateurs,” n’est-ce pas ?
Alors, roulement de tambour… Et lorsque l’ensemble de données a été mis à jour, malheureusement, les utilisateurs ont constaté une détérioration, et non une amélioration. Par exemple, notre principale métrique, disons le LCP, est passée de 73 % à 70 %.
J’étais déçu. Ce que nous avions fait ici relevait d’un coup à l’aveugle. Et cela fait mal en tant que consultant, car mon travail au quotidien est d’aider mes clients à avoir un impact et à rendre leurs sites web plus rapides pour les utilisateurs réels. J’ai donc dû réfléchir pour comprendre pourquoi cela s’était produit et pourquoi il y avait un décalage entre les données de Google Lighthouse et celles des utilisateurs, ce qui est frustrant. Nous devons justifier notre travail auprès de nos clients.
Nous étions enthousiastes : le score Google Lighthouse s’était amélioré, mais au final, nous n’avons pas aidé nos utilisateurs. Alors, quel est le problème avec le système de notation de Google Lighthouse ? C’est la question que j’ai tenté de résoudre, et ce n’était pas simple.
Quel est le problème avec le score Google Lighthouse ?
Prenons un exemple : imaginons que nous ayons 100 utilisateurs sur notre site. Ce que nous avons fait sur la page PLP, est-ce que cela reflète l’expérience d’un utilisateur ? Je ne sais pas. Peut-être que oui, peut-être que non.
Regardons un rapport PageSpeed Insights qui montre à la fois les données de Lighthouse et celles des utilisateurs réels, n’est-ce pas ? Désolé, mais c’est un vrai désordre. Ces données sont confuses.
Quand Google Lighthouse rapporte un score parfait de CLS (0 ici), 75 % de nos utilisateurs rencontrent un mauvais score de CLS.
De même, lorsque nous examinons le LCP, 75 % de nos utilisateurs ont un LCP parfait, ce qui est excellent, alors que Google Lighthouse indique un LCP de 3 secondes, ce qui n’est pas vraiment bon.
Cela ne me surprend pas, car l’émulation n’est pas la réalité. Désolé, Nintendo, mais jouer au tennis dans la vraie vie n’a rien à voir avec jouer au tennis sur une console de jeu…
Beaucoup se vantent de leurs réussites avec Google Lighthouse.
Chaque jour, de nombreuses personnes se vantent de leurs réussites avec Google Lighthouse. Oui, le score parfait, 100, ce qui est bien, car, d’une certaine manière, cela montre que nous progressons. Peut-être que cela impacte réellement vos utilisateurs, ou peut-être pas. Mais je comprends profondément ces personnes, car j’en ai fait partie moi aussi en 2018.
L’obsession pour les scores de performance web n’est pas nouvelle. En tant qu’humains, nous avons toujours été conditionnés et obsédés par les notes et les évaluations : système éducatif, examens médicaux, etc.
Le score Google Lighthouse est-il corrélé aux données des utilisateurs ?
Reprenons. Les données de Google Lighthouse ne correspondent pas aux données des utilisateurs. Mais y a-t-il au moins une corrélation entre elles ?
Brendan Kenny, un employé de Google, a mené une recherche sur les données de HTTP Archive et a découvert que 50 % des pages ayant un score parfait sur Google Lighthouse ne réussissent pas les Web Vitals, 50 % ! Cela signifie que vous avez une chance sur deux avec un score de 100 sur Lighthouse.
Mais ce n’est pas tout : avec un score de 50, il est également possible de passer l’évaluation des Web Vitals. Il y a donc un angle mort quelque part dans le système de notation de Google Lighthouse, n’est-ce pas ?
La question est donc : ont-ils quelque chose en commun ? Bien sûr, oui. Tous deux chargent des pages web avec un appareil ou une émulation d’appareil, et dans un certain contexte, n’est-ce pas ?
Cependant, la principale différence est que les utilisateurs interagissent avec votre site web : ils achètent des produits, zooment, scrollent et remplissent des formulaires, ce que Google Lighthouse ne fait pas.
En parlant de métriques… désolé pour le First Input Delay ou Interaction to Next Paint, car Google Lighthouse n’interagit pas.
- Lighthouse ne rapporte qu’un CLS partiel (au-dessus de la ligne de flottaison), sans scroll.
- Le LCP dépend des conditions du test.
En fin de compte, ils ne partagent pas autant de métriques que ce que l’on pourrait penser.
Google Lighthouse a des problèmes de variabilité :
Un jour, un développeur m’a envoyé une question par e-mail en me demandant pourquoi, lorsqu’on effectue trois tests consécutifs sur la même page, dans les mêmes conditions, on n’obtient jamais le même score.
Voici ma réponse : “C’est comme Pierre, Papier, Ciseaux !”
Parfois, vous ne pouvez même pas affirmer que le score s’est amélioré grâce à vos actions…
On peut tromper/tricher avec le score de Google Lighthouse :
Barry Pollard a publié un article intitulé “Making the Slowest Fast Page“, où il montre comment obtenir un score parfait sur Lighthouse tout en offrant une expérience utilisateur désastreuse.
Il y a trois mois, l’agence web de l’un de mes clients nous a envoyé un e-mail avec une capture d’écran, annonçant : “Nous avons corrigé tous les problèmes de performance web sur le site !!!”
Et j’ai répondu : “Pardon ?” J’ai vérifié le site, et là… Oh mon Dieu, ils avaient “hacké” le site. Ils avaient ajouté ce code directement dans le code source.
S’il vous plaît, ne faites pas ça. Vous ne faites que tromper les gens. Vous manipulez le score de Google Lighthouse, et de toute façon, ce score n’a aucun impact direct sur le SEO.
Donc, oui, ce code est un code de cloaking. Il vérifie si la page est chargée avec Google Lighthouse ou non, et, si c’est le cas, il charge uniquement le HTML. “Nous avons résolu tous les problèmes de performance web, on peut rentrer chez nous, nous n’avons plus besoin de consultants ni d’agences.”
J’ai répondu : “Vous vous souciez principalement de vos utilisateurs ou de Google Lighthouse ?” Voilà la vraie question.
Vos utilisateurs sont différents
Vos utilisateurs sont différents. Et comme Nick l’a mentionné, nous faisons souvent des suppositions : la 3G, la 4G, la 5G sont partout, et les CPU des appareils deviennent plus rapides chaque année.
Mais savez-vous quoi ? J’ai consulté le rapport des appareils dans Google Analytics, et l’iPhone est notre appareil le plus utilisé par notre audience. Oui, l’iPhone, partout.
Je suis désolé, mais vous faites des suppositions, car l’iPhone ne reflète pas la réalité. Seulement 30 % des parts de marché mondiales sont détenues par l’iPhone, iOS et les appareils Google, tandis que 70 % sont des appareils Android.
Alors, écoutez-moi bien. Vos utilisateurs ont potentiellement des appareils de 2019 ou 2020, avec peut-être un écran fissuré. En tant qu’utilisateur, je ne me soucie pas de votre score Google Lighthouse, de votre stack technique, ou même si c’est propulsé par ChatGPT. On s’en fiche. Ce que nous voulons, c’est accéder à des informations ou accomplir une tâche. Je cherche une assurance, je veux acheter un produit, et votre histoire de score technique ne m’intéresse pas, n’est-ce pas ?
Fiez-vous aux données de vos utilisateurs pour la performance web
Grâce à ce travail de réflexion, j’ai pu transformer mon workflow de performance web, qui avait échoué, et créer Speetals, un outil de monitoring basé sur les données des utilisateurs réels. J’ai donc transformé mon workflow en intégrant cette approche.
Si vous voulez avoir un impact sur les données de vos utilisateurs, vous devez commencer par les auditer. Si vous voulez influencer quelque chose, vous devez le surveiller pour pouvoir l’auditer, et non pas utiliser des outils qui ne représentent pas vos utilisateurs.
Commencez donc par auditer dans le champ réel, c’est-à-dire sur les données des utilisateurs, et validez rapidement vos optimisations à partir de ces mêmes données. Entre ces deux étapes, bien sûr, nous allons utiliser des outils synthétiques : Lighthouse, Chrome DevTools ou votre outil préféré sur le marché, n’est-ce pas ?
Écoutez l’expérience de vos utilisateurs et validez vos efforts avec eux. C’est l’essence même de ce workflow.
Bien entendu, dès la première étape, vous pouvez utiliser votre propre outil de Real User Monitoring. Vous pouvez vous amuser à écrire vos requêtes SQL, créer vos tableaux de bord Looker Studio ou exploiter les données CrUX. Pour rendre cela plus simple et accessible, j’ai créé Speetals, un outil conçu pour faciliter ce processus de manière fluide et efficace.
Commençons par la première étape. Nous devons écouter l’expérience de nos utilisateurs.
Nous n’allons plus parler de scores. Nous allons parler de distributions : les distributions verte, orange et rouge, c’est-à-dire bon, moyen, mauvais, n’est-ce pas ?
Lorsque j’audite la performance d’un site web, je mets mobile et desktop côte à côte. Cela m’aide à identifier les points d’amélioration, mais aussi les écarts dans les distributions. Parfois, nous supposons que si notre CLS sur mobile est bon, celui sur desktop le sera aussi, ce qui n’est pas toujours vrai.
Par exemple, ici, nous avons un problème de First Input Delay (FID) sur mobile, ce qui est plus logique à observer, car les interactions nécessitent des CPU, etc.
Donc, comparez toujours les appareils et les distributions à travers les différentes métriques. Cela vous permettra d’avoir une vue d’ensemble et de prioriser vos efforts d’optimisation.
Ici, je montre uniquement les métriques des Web Vitals, mais j’analyse également le Time to First Byte (TTFB), le First Contentful Paint (FCP), et l’INP, la nouvelle métrique des Core Web Vitals.
Une autre chose que j’adore faire, et qui est très utile, c’est visualiser comment chaque métrique se distribue sur chaque appareil grâce à un histogramme.
Prenons cet exemple : un histogramme du LCP qui montre comment nos utilisateurs expérimentent le LCP.
- Sur l’axe X, nous avons les valeurs du LCP en millisecondes.
- Sur l’axe Y, nous avons le pourcentage d’utilisateurs.
- Les marqueurs montrent les seuils pour “bon”, “moyen” et “mauvais”.
Voyez ce P75 ? Cela représente le 75e centile, ce qui signifie que 75 % de vos utilisateurs ont un LCP de 6 secondes, ce qui est énorme et beaucoup trop élevé.
Comment optimiser ?
Lorsque nous optimisons la performance web, l’objectif est de pousser les utilisateurs vers la gauche sur l’axe X, c’est-à-dire dans la zone verte, la zone de sécurité.
Si le P75 se déplace dans la zone verte, la métrique sera validée, et le site passera les Web Vitals. Cela doit être notre objectif lorsque nous améliorons la performance.
Une autre chose que j’aime faire, et qui est très utile, c’est de comparer la distribution des métriques avec celle de la concurrence.
Je ne vais pas citer de marque, mais il est souvent surprenant et choquant de constater que votre site a de moins bonnes performances que vos concurrents.
Cette comparaison peut :
- Aider à fixer des objectifs réalistes et atteignables.
- Motiver les équipes à adopter une culture de la performance en interne, en disant : “Oui, d’accord, allons rivaliser avec eux.”
Cela peut être un excellent levier pour inciter les équipes à s’améliorer et à viser des performances à la hauteur de celles des leaders du marché.
Qui ici gère un site web international ? Super. N’oubliez pas de comparer la distribution de votre audience sur chacun de vos marchés ciblés.
Voici un exemple avec l’un de mes clients, une marketplace basée en France, mais qui opère à l’international sous le même nom de domaine, un domaine en .com.
Il est crucial d’analyser les écarts entre les utilisateurs dans des régions comme les pays européens et ceux du Moyen-Orient.
C’est une étape essentielle à ne pas négliger, car ces différences peuvent avoir un impact majeur sur la perception de la performance et l’expérience utilisateur.
Étape deux.
D’accord, nous avons beaucoup de données au niveau du domaine : distributions, métriques, etc. Nous savons déjà sur quelle métrique et sur quel appareil travailler pour optimiser les performances. Maintenant, il est essentiel de faire les bonnes choses en priorité pour maximiser l’impact.
Transition des données de domaine aux données de page
Il est inutile de surveiller toutes les pages de votre site web. Cela n’a pas de sens. Ce qui est vraiment pertinent, c’est de se concentrer sur vos pages principales. Par exemple :
- Les pages PLP (Product Listing Pages)
- La page d’inscription
- La page d’aide
- Les articles de blog
- Les pages PDP (Product Detail Pages), etc.
Que faire ?
Je trie ces pages par performance décroissante sur chaque métrique. Par exemple, ici, je les ai triées par LCP.
Si vous voulez améliorer l’expérience de 60 % des utilisateurs sur mobile ou desktop, commencez par optimiser les types de pages les plus problématiques. Cela pourrait être une catégorie principale qui a la plus grande proportion de distributions rouges pour le LCP, ce qui est un low-hanging fruit (un fruit facile à atteindre).
En ciblant les pages avec les pires performances, vous obtiendrez des gains rapides et significatifs.
Étape trois.
Voici ce que je faisais en 2017 : implémenter et tester en laboratoire. Vous pouvez utiliser Google Lighthouse. J’aime Lighthouse.
Et, bien sûr, l’étape la plus importante : valider. Vous et votre équipe client avez fait des efforts et investi du temps et de l’argent pour améliorer la performance web. Maintenant, il faut s’assurer si vous avez atteint vos objectifs ou non.
Ne pas attendre 28 jours
Attendre 28 jours (cycle mensuel de CrUX) pour valider est trop tard. Vous ne saurez pas si vous avez eu un impact réel. À la place, utilisez une validation quotidienne basée sur les données CrUX.
Exemple
- Nous avons déployé une correction sur les PDP (Product Detail Pages), notamment le CLS sur desktop.
- Deux jours après le déploiement, nous avons constaté une amélioration de 34 %.
- Ce processus permet de voir rapidement si vos optimisations améliorent ou détériorent les performances.
Importance des cycles courts
Il est crucial d’avoir un rythme d’itérations et de validations dans une fenêtre d’une semaine.
Vous n’avez pas besoin de plus de temps pour valider vos efforts d’optimisation. Cela permet de maintenir une cadence rapide et efficace dans vos projets.
Un autre exemple :
Une amélioration de 7 % sur le LCP mobile de la page PLP (Product Listing Page).
- Déployé, validé, puis vous passez à d’autres tickets et optimisations, et vous itérez.
C’est le principe de mon workflow et de ma méthodologie.
Rappelez-vous du 75e centile
Lorsque vous améliorez la distribution verte, votre graphique du 75e centile doit descendre. Cela signifie que vous poussez les utilisateurs vers la gauche, dans la zone verte.
Exemple concret
Ici, notre 75e centile est passé de 4 secondes à 2 secondes, ce qui est excellent. Cela indique que la métrique est passée d’une distribution rouge dans les Web Vitals à une distribution verte. Résultat : validé.
Et souvenez-vous de ma frustration. Vous pouvez l’éviter en détectant rapidement les régressions. C’est tellement important.
Exemple concret
Une régression est survenue sur la page PDP (Product Detail Page), car l’équipe marketing a décidé d’ajouter un widget de commentaires glissants. Chaque commentaire ayant une taille différente, cela a généré un CLS très élevé.
Réagir rapidement grâce aux alertes
Grâce aux alertes Slack, nous avons pu détecter cette régression rapidement et réagir tout aussi vite. Cela montre l’importance d’un système de surveillance efficace pour prévenir les problèmes avant qu’ils n’affectent trop gravement les utilisateurs.
Bien sûr, enfin, nous devons toujours valider mensuellement pour confirmer les résultats, mais aussi pour réaliser des rapports destinés à la direction. C’est une façon de montrer que les efforts et les investissements réalisés ont porté leurs fruits et ont été validés.
Importance du reporting
Cette validation régulière est essentielle pour :
- Maintenir l’engagement de la direction.
- Continuer à obtenir du soutien pour les initiatives liées à la performance web.
Exemple concret
Dans cet exemple, le site a subi une migration qui a causé une perte importante de performance web. À partir de là, nous avons commencé à travailler sur l’optimisation des performances pour inverser la tendance.
Le suivi et la validation mensuels permettent de démontrer les progrès et d’encourager une dynamique continue.
En résumé :
Ne vous fiez jamais uniquement à Google Lighthouse pour surveiller la performance web. Utilisez Lighthouse, utilisez vos outils synthétiques, mais concentrez-vous principalement sur les données de vos utilisateurs.
Pourquoi ? Parce qu’à la fin de la journée, ce sont vos utilisateurs qui achètent vos services ou produits, et non Google Lighthouse.
Points clés :
- La validation rapide est cruciale. Ne perdez pas 28 jours. Adoptez un cycle court pour valider vos efforts et mesurer les résultats.
- Concentrez-vous sur vos utilisateurs, optimisez pour eux, et profitez du processus.
Merci beaucoup d’être venus, merci de votre attention, et merci, Brighton !
Surveillez votre site avec Speetals, un outil de vitesse centré sur l’utilisateur. Priorisez, optimisez, validez et recommencez !
