Image
Core Web Vitals, la nouvelle référence

SEO : les Core Web Vitals sont dorénavant la référence

SEO
Core Web Vitals
UX
Performances

Octobre 2022 : Google met à jour ses conseils officiels SEO pour les webmasters, sous le nom désormais de « Google Search Essentials ». 

Dorénavant, pour calculer le référencement naturel d'un page d'un point de vue technique, Google s’appuie sur 3 critères mesurables principaux, regroupés sous l’appellation de « Core Web Vitals ».
 

Les Core Web Vitals, c'est quoi ?

Les Core Web Vitals sont un ensemble de mesures qui évaluent l'expérience utilisateur sur des critères tels que les performances de chargement, la réactivité aux entrées de l'utilisateur et la stabilité de la mise en page. 

Non seulement l’optimisation de ces critères améliore l’expérience utilisateur, mais c’ est aujourd’hui une démarche indispensable pour avoir un bon référencement naturel (SEO). 
En effet, là où auparavant Google s'intéressait des critères tels que les performances générales d'affichage au milieu de plein d'autres (par exemple la présence d'une version AMP des pages en mobile), pour ranker le référencement d'une page, il accorde aujourd'hui la priorité à l'optimisation de ces critères précis, et particulièrement sur les 3 que nous allons détailler.

L'optimisation de la qualité de l'expérience utilisateur est la clé du succès à long terme de tout site sur le Web.
Philippe Walton - Ingénieur Google - Présentation des Core Web Vitals

L'objectif est d'obtenir une expérience utilisateur satisfaisante, examinée selon 3 axes principaux :

  • la vitesse d'affichage (LCP), en se focalisant sur le chargement du contenu principal de la page,
  • l'interactivité (FID), en observant la réactivité de la page suite à une interaction,
  • la stabilité visuelle (CLS), en analysant les changements de mise en page.
Image
Google Core Web Vitals

Chacun des Core Web Vitals représente une facette distincte de l'expérience utilisateur, est mesurable sur le terrain.

Pourquoi optimiser ces critères ?

Les données remontées par les Core Web Vitals reflètent le résultat d'une réelle expérience centrée sur l'utilisateur.

Des recherches Google montrent d'ailleurs que les Core Web Vitals améliorent l'engagement utilisateur et les métriques métier.
Par exemple, en analysant des millions d'impressions de pages pour comprendre comment ces seuils affectent les utilisateurs, les études ont montré que les utilisateurs étaient 24 % moins susceptibles d'abandonner le chargement de la page (en quittant la page avant que le contenu ne soit affiché) lorsqu'ils sont respectés. Les résultats sont similaires concernant le e-commerce.
Il est à noter qu'il y a peu d'interventions qui peuvent montrer ce niveau d'amélioration pour les entreprises en ligne.

L'optimisation de ces facteurs contribuera à accroître la satisfaction des internautes, indépendamment de leur navigateur Web ou de leur plate-forme. Parallèlement, les propriétaires de sites seront plus à même de répondre aux attentes des mobinautes. Il y a fort à parier que l'accroissement de l'engagement, et la simplification des échanges qui devraient découler de ces améliorations, auront un impact positif sur les résultats des entreprises sur le Web.

Comment mesurer les Core Web Vitals ?

Google estime que les Core Web Vitals sont essentiels à toutes les expériences Web. Par conséquent, il s'engage à faire apparaître ces mesures dans tous ses outils populaires et met à disposition les données à remonter.

Ainsi, plusieurs outils en ligne sont disponibles afin d'obtenir une évaluation de ces métriques, tel que le ferait Google. Vous pouvez par exemple utiliser PageSpeed Insights  ou WebPageTest  qui permettent non seulement d'examiner les données souhaitées, mais aussi d'obtenir une liste de points d'améliorations personnalisées afin d'optimiser le score de la page soumise à examen.

Voici un exemple avec la homepage d'un projet récent de l'agence Koriolis examinée avec PageSpeed Insights.
On retrouve les 3 métriques dans les données remontées.

Comme on peut s'en douter, l'idéal est évidemment d'avoir des valeurs situées dans la zone verte, aussi bien en mobile qu'en desktop, et pour chaque page que l'on souhaite voir bien référencée.

Image
Outil de mesure des Core Web Vitals

Semruch a également mis en place des rapports dédiés aux Core Web Vitals, cependant il est réservé aux abonnés.

La Search Console mesure aussi le trafic de recherche et les performances de votre site, y compris Core Web Vitals . Une fonctionnalité intéressante de la Search Console est qu'elle évalue des groupes de pages similaires (par exemple, des pages qui utilisent le même modèle).

Pour les développeurs, Lighthouse est un outil qui offre des opportunités spécifiques pour améliorer les performances des pages, leur permettant de créer des scripts de flux d'interaction pour les tests de performances au-delà du démarrage de la page.
L'onglet Performances de Chrome DevTools doit être utilisé par les développeurs pour obtenir un aperçu approfondi des performances de la page. Il peut être utilisé avec Lighthouse ou d'autres outils qui exportent des indices de performances, qui peuvent ensuite être chargés dans l'onglet Performances .

Comment optimiser ses pages pour obtenir de bonnes métriques ?

Optimisation du LCP

Le LCP, pour Largest Content Paint (TDLR : rendu du plus grand contenu), représente la rapidité avec laquelle le contenu principal d'une page web est chargé. Plus précisément, il mesure le temps entre le moment où l'utilisateur initie le chargement de la page, et le rendu de la plus grande image ou du plus grand bloc de texte dans la fenêtre d'affichage.

Pour offrir une bonne expérience utilisateur, les sites doivent s'efforcer d'avoir un LCP de 2,5 secondes ou moins pour au moins 75 % des visites de pages.

Il est rare qu'une solution rapide pour une seule partie d'une page se traduise par une amélioration significative de LCP. Pour améliorer LCP, vous devez examiner l'ensemble du processus de chargement et vous assurer que chaque étape du processus est optimisée.

La plupart des chargements de pages incluent généralement un certain nombre de requêtes réseau, mais pour identifier les opportunités d'amélioration de LCP, vous devez commencer par en examiner seulement deux :

  1. le document HTML,
  2. la ressource LCP (le cas échéant).

 

Une bonne façon de penser à la répartition du temps LCP est :

  • la grande majorité du temps LCP doit être consacrée au chargement du document HTML et des ressources nécessaires au LCP.
  • tout moment où l'une de ces ressources du LCP ne se charge pas est une opportunité d'amélioration.

Pour une page bien optimisée, vous souhaitez que votre demande de ressource LCP commence à se charger le plus tôt possible, et que l'élément LCP s'affiche aussi rapidement que possible une fois le chargement de la ressource LCP terminé. Pour aider à visualiser si une page particulière suit ou non ce principe, vous pouvez décomposer le temps LCP total dans les sous-parties.

Image
LCP timeline
Comme dans cet exemple, la valeur LCP peut être décomposée en ces 4 sous-parties, sans chevauchement ou écart entre elles, et totalise leur temps collectif. Il est nécessaire d'optimiser toutes ces sous-parties afin d'obtenir de meilleurs résultats.

L'optimisation du LCP étant une tâche complexe, il est généralement préférable de les décomposer en tâches plus petites et plus gérables, puis de les traiter séparément.

Concrètement, les premières actions à mener sont en général les suivantes :

1. éliminer le délai de chargement des ressources,
2. éliminer le délai de rendu des éléments,
3. réduire le temps de chargement des ressources,
4. réduire le temps au premier octet.

Optimisation du FID

Le FID, pour First Interaction Delay (TDLR : durée de première interaction), est une métrique Core Web Vitals qui représente la première impression d'un utilisateur sur l'interactivité et la réactivité d'un site. Elle mesure le temps entre le moment où un utilisateur interagit pour la première fois avec une page et le moment où le navigateur est réellement capable de répondre à cette interaction.

Pour offrir une expérience utilisateur de qualité, assurez-vous que le FID soit inférieur à 100 millisecondes.

Le FID est une métrique qui ne peut pas être simulée dans un environnement de laboratoire : une interaction réelle de l'utilisateur est nécessaire pour mesurer le délai de réponse.

La principale cause d'un mauvais FID est l'exécution de JavaScript lourds. L'optimisation de la façon dont JavaScript analyse, compile et s'exécute sur votre page Web réduira directement le FID.

Limiter la quantité de JavaScript sur votre page réduit le temps que le navigateur doit consacrer à l'exécution du code JavaScript. Cela accélère la vitesse à laquelle le navigateur peut commencer à répondre à toute interaction de l'utilisateur.

Pour réduire la quantité de JavaScript exécuté sur votre page :

  • différer le JavaScript inutilisé
  • minimiser les fichiers utilisés
     

Si vous avez déjà tenté de réduire la quantité de JavaScript qui se charge sur une seule page, il peut être utile de décomposer le code de longue durée en tâches asynchrones plus petites.

Il existe un certain nombre de causes courantes de mauvais scores FID qui dépendent fortement de JavaScript :

  • l'exécution de scripts de première partie peut retarder la préparation à l'interaction
  • la récupération de données peut avoir un impact sur de nombreux aspects de la préparation à l'interaction
  • l'exécution de scripts tiers peut également retarder la latence d'interaction

Par exemple, en déplaçant hors du chemin critique le chargement (et l'exécution) des scripts coûteux liés à un composant non essentiel, les utilisateurs peuvent interagir avec la page beaucoup plus tôt, impactant ainsi le FID.

Le FID devrait s'améliorer sensiblement à mesure que vous adoptez les meilleures pratiques telles que le fractionnement de code et la décomposition de vos tâches longues.

 

Optimisation du CLS

Le CLS, pour Contant Layout Stabilité (TDLR : stabilité d'affichage des contenus), mesure l'instabilité du contenu en additionnant les "scores de changement" issus des changements de mise en page qui ne se produisent pas dans les 500 ms suivant l'entrée de l'utilisateur. Il examine la quantité de contenu visible déplacé dans la fenêtre d'affichage ainsi que la distance à laquelle les éléments impactés ont été déplacés.

Le score CLS doit être inférieur à 0,1, le plus proche possible de 0.

Les changements de mise en page sont très courants sur le web et provoque une expérience négative en perturbant l'utilisateur qui consulte son contenu.
ls surviennent souvent lorsque des éléments visibles sont forcés de se déplacer parce qu'un autre élément a été soudainement ajouté à la page ou redimensionné.

Les causes les plus courantes d'un mauvais CLS sont :

  • les images sans dimensions dans le HTML,
  • les annonces, intégrations et iframes sans dimensions,
  • les contenus injectés dynamiquement, comme par exemple ceux remontés en Ajax,
  • le chargement des polices,
  • les actions en attente d'une réponse réseau avant de mettre à jour DOM.

Pour s'assurer que le contenu reste statique, il faut notamment s'assurer que le chargement des images ne sera pas responsable du décalage des autres blocs.

C'est souvent une situation à gérer lorsqu'il y a affichage d'une bannière publicitaire au dessus du contenu de la page sans qu'un espace n'est été prévu dans le HTML avant son chargement.

Image
CLS sans placeholder
Comportement d'une page sans placeholder

Un exemple de bonne pratique améliorant le CLS est de prévoir un placeholder, c'est-à-dire un bloc fantôme aux dimensions de la bannière, qui sera remplacé par celle-ci dès son chargement.

Ce bloc doit évidemment lui aussi s'adapter de la même façon que la bannière selon les différents devices.

La situation se complexifie encore lorsque vos bannières peuvent avoir des hauteurs différentes selon la campagne en cours d'affichage.

Image
CLS avec placeholder
Comportement d'une page avec un placeholder

Drupal et les Core Web Vitals

Drupal ayant travaillé l'optimisation de ces bonnes pratiques de développement depuis plusieurs versions majeures, il est déjà opérationnel pour cette nouvelle norme.
Ainsi les standards du coeur de Drupal et des modules communautaires sont de base Core Web Vitals Friendly, là où d'autres CMS requièrent des patchs et dépendent des mises-à-jour de leurs modules pour s'y adapter.

Articles pouvant vous interesser

Image
Images responsives, écrans rétina ready et format Webp
Responsive Image
Webp
Retina
Performances
Image
A quoi s'attendre avec Drupal 10
Drupal 10