Beaucoup d’articles traitent des Core Web Vitals, mais peu d’entre eux couvrent leurs limites. J’ai pensé utile de partager quelques informations à ce sujet.
Les Core Web Vitals sont sous les feux de la rampe de la performance web depuis que l’équipe Web Dev de Google les a présentés comme le nouveau cadre d’évaluation de l’expérience utilisateur sur un site web. Google a annoncé en novembre 2020 que l’expérience reflétée par les Core Web Vitals influencerait les rangs SEO à partir de mai 2021. Ceci a un impact majeur sur de nombreuses sociétés qui dépendent de leur site web pour engendrer des revenus. Beaucoup de discussions relatives à la performance web se sont focalisées exclusivement sur les Core Web Vitals pour cette raison.
Ceci dit, les Core Web Vitals ont des limitations :
- ils ne reflètent pas tous les aspects de l’expérience utilisateur
- ils ne sont pas significatifs pour tous les sites.
Regardons de plus près et clarifions leurs lacunes et les situations où ce moyen de supervision est adapté ou pas.
Quelles sont les principales limitations des Core Web Vitals ?
Les Core Web Vitals sont structurés autour de 3 métriques qui reflètent 3 aspects de l’expérience utilisateur :
- LCP (Largest Contentful Paint) reflète la vitesse à laquelle un utilisateur commence à voir un élément visuel de grande taille apparaître dans son navigateur (n’importe quel objet comme une image, un texte ou une vidéo etc…).
- FID (First Input Delay) mesure l’interactivité ou la vitesse à laquelle le navigateur sera occupé après la première interaction utilisateur (exemple : un clic de souris).
- CLS (Cumulative Layout Shift) mesure la stabilité visuelle et si l’utilisateur est dérangé ou non par des contenus déplacés sur l’écran pendant l’affichage d’un autre contenu.
Clairement, les Core Web Vitals apportent des améliorations importantes comparés aux jeux de métriques précédents (comme les temps de chargement des pages, TTFB, FCP, etc…).
Quelles sont les limites de Core Web Vitals, alors ?
Vitesse d’affichage / LCP
Ces métriques sont significatives si la majeure partie de l’expérience utilisateur est conditionnée par la vitesse de chargement des pages.
Actuellement, ce n’est pas toujours le cas : pour les applications web (comme la plupart des applications SaaS) mais aussi pour un nombre croissant de sites web (comme les réseaux sociaux), le chargement d’une page est une toute petite partie de l’expérience utilisateur : web progressif ou application monopage (SPA – Single Page Applications). Les applications monopage chargent initialement un “bundle” (contenant un ensemble de feuilles de style et de javascripts). La plupart des interactions utilisateur n’impliquent pas le chargement de pages supplémentaires, mais l’exécution de javascripts et l’appel d’API Web pour fournir et exécuter des fonctions et afficher des contenus supplémentaires.
La situation a deux conséquences :
- Les mesures de chargement de page (PLT – Page Load Times) et de LCP sont exceptionnelles. Un utilisateur ne peut charger une page qu’un nombre de fois limité par jour tout en utilisant un site web à plein temps.
- Du point de vue de l’utilisateur, la performance mesurée par le LCP est relativement vide de sens : dans la plupart des cas, elle consiste à charger visuellement un logo au milieu d’une page.
Que mesure LCP pour un site comme www.linkedin.com ?
Cela signifie que l’expérience utilisateur réelle mesurée par LCP est l’apparition du logo Linkedin lors du chargement initial de la page. Si l’opération était lente, LCP fournirait des informations (mais est-ce vraiment un défi sur les performances web d’afficher un logo dans un délai court ?😅 ).
First Input Delay pour mesurer l’interactivité
FID a pour objectif de mesurer l’interactivité et la réactivité de l’interface de vos utilisateurs. Techniquement parlant, il mesure l’intervalle de temps entre la première interaction de l’utilisateur (par exemple un clic de souris) et le moment où le navigateur est en mesure de réagir à cette interaction (lire cet article pour plus d’informations sur le FID).
C’est un bon point de départ, mais encore une fois, pour les sites Web progressifs et les applications monopage, la toute première interaction est un échantillon trop petit des activités de l’utilisateur pour être significatif.
Par exemple, le tableau ci-dessous représente le nombre d’appels passés par un utilisateur sur linkedin.com selon le type d’initiateur :
- il ne peut y avoir plus de « première entrée utilisateur » (First Inputs) que de chargements de pages (ici Navigation = 377 éléments),
- le nombre d’opérations XHR (XmlHTTPRequests), scripts et fetchs qui ont généré des requêtes sur le réseau (par exemple, les appels API pour afficher les données sous toutes les formes) représente plus de 3,1 k opérations.
Le FID représente au mieux 10 % des interactions de l’utilisateur.[
Quand faut-il vous appuyer sur les Core Web Vitals… ou pas ?
Les Core Web Vitals sont parfaits pour certains sites…. Mais totalement inadaptés pour d’autres.
Vous pouvez vous appuyer sur les Core Web Vitals quand la plupart des interactions utilisateurs consistent à charger des pages supplémentaires.
Si vos plateformes Web sont constituées de :
- Applications Web progressives
- Applications monopages
Vous vous souciez peut-être de Core Web Vitals en raison de son influence sur le classement SEO. Cependant les Core Web Vitals seront très insuffisants pour vous assurer de garder votre expérience utilisateur sous contrôle.
Si tel est votre cas, je vous recommande vivement de regarder de plus près cet article sur « Comment surveiller l’expérience utilisateur pour les applications à monopage (SPA) ».
