Il y a quelques semaines, Google a créé une nouvelle appellation pour un jeu d’indicateurs de mesure de l’expérience utilisateur : les Core Web Vitals, ou Signaux Web Essentiels. La nouvelle fait grand bruit dans le monde du SEO, car Google souhaite faire de ces indicateurs des critères de ranking l’année prochaine.
Le déploiement est prévu en mai 2021.
Prenons un peu de recul.
Préambule 1 : qu’est-ce qu’un bon indicateur pour le marché ? À mon sens, c’est un indicateur qui mesure ce qu’il dit mesurer et qui, une fois cette mesure effectuée et les valeurs connues, aide à prendre des décisions pour améliorer l’expérience utilisateur.
Préambule 2 : les Web Vitals ne sont pas figés. Ce sont juste les indicateurs que Google met pour l’instant en avant dans ses outils de mesure de la performance. Comme ils le disent eux-mêmes :
[…] these signals are not perfect and future improvements or additions should be expected.
Rien ne garantit donc, même si c’est probable, que les indicateurs mis en avant aujourd’hui soient, l’année prochaine, toujours d’actualité. Pour rappel, Google a auparavant fait la promotion d’autres indicateurs, comme le Time To Interactive, avant d’en revoir l’appréciation à la baisse dans des itérations ultérieures de leurs outils (à raison).
De ce que j’ai vu du Cumulative Layout Shift, je pense qu’il sera également remplacé à moyen terme par un indicateur de meilleure qualité.
Suite aux critiques des équipes de développement de SPAs, la réflexion semble avoir commencé.
Préambule 3 : bien que la Performance Web soit mise en avant depuis des années par Google comme critère de ranking, et encore plus depuis la Speed Update, très peu de retours de terrain le confirment. Il semblerait que la Performance Web est plutôt, pour l’instant, un signal faible utilisé éventuellement pour de la pénalisation.
Cela ne veut pas dire que la Performance n’est pas utile : elle bénéficie au crawl et à l’expérience des personnes qui visitent vos sites, réduisant vos rebonds, améliorant votre conversion… C’est déjà énorme.
En revanche, c’est la première fois que Google communique explicitement sur des indicateurs utilisés. C’est très intéressant parce qu’on a vu plusieurs indicateurs être mis en avant au fil des années, notamment le Speed Index, et il a fallu attendre d’avoir un jeu d’indicateurs faciles à collecter pour eux (ne nécessitant pas l’usage d’une vidéo) pour que cette annonce soit faite.
Il y a donc fort à parier que le Speed Index n’a jamais été un indicateur calculé à l’échelle par Google, pour évaluer le ranking.
Dernier préambule : je pense que cette nouvelle dénomination de Signaux Essentiels ne va pas constituer une opportunité pour le monde du SEO. Comme le dit Olivier Andrieu :
L’UX ne sera jamais un critère SEO majeur. « Core Web Vitals : l’UX bientôt pris en compte par Google ? Prenons du recul… »
En revanche, c’est une opportunité intéressante pour les professionnels de l’Expérience Utilisateur, qui pourrait y voir une première phase peu coûteuse d’approche quantitative, préliminaire à une phase d’étude qualitative plus spécifique à l’usage étudié.
Et si c’est une clé pour l’UX, c’est donc aussi une clé pour le SXO (Search Experience Optimization).
Fin de la mise en bouche, parlons des Web Vitals en eux-mêmes !
Le First Contentful Paint (FCP) est facile à collecter (puisque fourni directement par Chrome), son nom correspond à sa définition et celle-ci est simple à comprendre, même si elle présente un petit souci dès qu’on utilise des Web Fonts. En savoir plus.
Le LCP (Largest Contentful Paint) indique le moment où est rendu le plus grand élément de contenu réellement visible dans le viewport. C’est un indicateur dont l’objectif est de mesurer ce que ressent l’utilisateur du chargement visuel de la page, à l’instar du Speed Index.
Le nom du LCP est explicite, correspond à sa définition et l’indicateur est facile à collecter. Nous allons donc le croiser de plus en plus. Je lui préfère le Speed Index, qui s’intéresse à la progressivité du rendu de l’ensemble de la page mais c’est sans importance : sur la très grande majorité des pages, les deux indicateurs sont très fortement corrélés.
Cela permet néanmoins de savoir que si le Speed Index n’est pas disponible dans l’outil de votre choix, le LCP sera probablement une très bonne alternative pour répondre à la question :
Quand la personne utilisant le site a-t-elle l’impression que la page est suffisamment chargée pour être utilisée ?
Le FID (First Input Delay) est une mesure réalisée auprès de vrais utilisateurs et utilisatrices (Real User Metric, RUM). Elle correspond au délai d’attente subi lors de la première interaction avec la page, quel qu’en soit le moment.
Le FID est facile à comprendre mais comme toutes les mesures « réelles », il présente l’inconvénient d’être peu utilisable sans l’observer dans sa distribution. Dit autrement : un FID « moyen » ne porte pas d’information en soi. Un point bien abordé dans cet article, qui montre deux distributions avec des valeurs agrégées similaires. Pourtant, l’expérience est très différente.
C’est la force ET la faiblesse du RUM : être capable de retranscrire la diversité des usages, mais ne pas faciliter la prise de décision et accompagner le suivi. Tout l’inverse de l’analyse Synthétique. RUM et synthétiques sont donc complémentaires. Gilles vous en dira plus.
En synthétique, trois indicateurs d’interactivit pris ensemble peuvent pallier l’absence du FID : le Max Potential FID (le pire FID possible), et le Total Blocking Time (TBT) (qu’on peut résumer de manière inexacte mais simple comme la somme des temps de frustration potentiels pendant le chargement) et le Time to Interactive (qui est, comme son nom ne l’indique pas du tout, le moment du dernier ralentissement notable durant le chargement).
À défaut d’avoir la répartition du First Input Delay en synthétique, nous pourrons bientôt disposer de sa valeur potentielle maximale, de l’espérance d’une frustration en divisant le TBT par la durée de la période sur laquelle il est agrégé (entre le First Contentful Paint et le Time To Interactive) et du moment après lequel le FID est négligeable à nul (le Time To Interactive).
Enfin, les Core Web Vitals intègrent le Cumulative Layout Shift (CLS). Son algorithme s’intéresse au déplacement des éléments durant le chargement, afin de détecter les modifications visuelles susceptibles de tromper ou frustrer l’utilisateur parce qu’elles déplacent des éléments. Si l’intention derrière le CLS est géniale – et que des propriétés CSS commencent à apparaitre pour limiter ces mouvements (comme contain) – je pense que nous manquons collectivement de recul sur l’algorithme, et donc sur l’indicateur lui-même.
Des choses seraient à creuser sur sa sensibilité à l’orientation, son rapport aux interactions et aux animations. J’ai en tête des exemple de pages très désagréables en termes de déplacement d’éléments, mais qui auraient un bon CLS. Le sujet est très complexe. Je ne suis pas certain que l’algorithme soit suffisament complexe pour être pertinent dans un contexte de ranking.
Depuis, j’ai pris le temps de décortiquer l’indicateur et son algorithme pour en liver une analyse : « Cumulative Layout Shift, l’indicateur de stabilité de la mise en page ».
Je ne sais pas ce que l’avenir nous réserve, mais d’autres mesures existent déjà, notamment du côté de la surveillance du curseur des utilisateurs (agitation frustrée, clics frénétiques…). Il y a donc encore un gros potentiel concernant l’expérience utilisateur. Philip en parle très bien.
Mais concrètement, on cherche toujours les mêmes informations depuis des années. On veut que l’utilisateur ait l’impression que la page :
- est disponible ;
- commence à s’afficher rapidement ;
- affiche vite les informations pertinentes ;
- est utilisable, correctement, peu de temps après l’affichage du contenu pertinent.
En regardant uniquement le Premier Octet et le Speed Index, on observe déjà bien les 3 premiers jalons temporels. Si ces métriques sont mauvaises, s’intéresser à l’interactivité est parfois prématuré, notamment en termes de maturité de l’équipe d’optimisation. D’expérience, excessivement peu de sites parviennent à déjà contrôler les trois premiers points…
Mais alors pourquoi inventer de nouveaux indicateurs alors qu’on pourrait continuer avec des indicateurs existants et des indicateurs personnalisés ?
Tout simplement, pour rendre le domaine de la Performance Web plus vivant, pour l’intégrer toujours davantage dans l’Expérience Utilisateur et créer de nouvelles dynamiques. Concrètement, les équipes chargées d’optimiser la Performance Web vont pouvoir négocier de nouveaux budgets.
Si ce n’est pas votre cas, pas de panique. Les fondamentaux de la Performance Web sont solides, et n’ont pas changé avec ces nouveaux signaux. Ce n’est pas parce que vous voyez des publications sur la corrélation entre de bons Core Web Vitals et des taux d’abandons réduits que cette corrélation n’existait pas déjà avant, avec les outils et indicateurs que vous utilisez peut-être déjà au quotidien.
Le cap est donc le même. Si vous n’arriviez pas à mobiliser des compétences pour corriger vos problèmes existants, il y a fort à parier que ces nouveaux signaux ne vous faciliteront pas la tâche. Mais si vous alliez déjà dans la bonne direction, vous continuerez probablement.
Dans les deux cas, je serais ravi de vous accompagner sur un bout du chemin.