Glossaire SEO : Google Core Web Vitals

Quels sont les Core Web Vitals existants et quelle est leur fonction ?

Google a défini trois Core Web Vitals qui s'occupent en particulier des conditions techniques d'un site web : À quelle vitesse les contenus sont-ils mis à disposition, quand le site web réagit-il à l'utilisateur et quelle est la stabilité des contenus visuels ? Pour mesurer cela, il existe les Core Web Vitals suivants :

 

1. Peinture au contenu plus large (LCP)
2. Interaction avec la peinture suivante (INP)
3. Décalage cumulatif de la mise en page (CLS)

 

Si tu t'es déjà penché sur le sujet, tu as peut-être remarqué qu'un Web Vital a disparu et qu'une nouvelle valeur a été ajoutée. Et effectivement : en mars 2024, Google a remplacé le Web Vital First Input Delay (FID) par la valeur de mesure Interaction to Next Paint (INP). Nous allons t'expliquer pourquoi. Pour l'instant, nous allons nous intéresser aux Core Web Vitals actuels et à leurs fonctions.

 

LCP : la vitesse de chargement d'un site web

Le Largest Contentful Paint (LCP) décrit le temps qui s'écoule jusqu'à ce que le contenu principal ou l'élément le plus pertinent pour l'utilisateur soit visible après un clic sur une page. Il ne s'agit dans un premier temps que du contenu Above The Fold - c'est-à-dire des blocs de texte ou des images qui apparaissent sur la page Web sans défiler.

 

Auparavant, au lieu du LCP, on mesurait généralement le temps nécessaire à l' apparition du premier élément sur la page web : le First Contentful Paint (FCP). Il pouvait s'agir par exemple de l'apparition des barres de chargement, de la table des matières ou de la barre de saisie dans les moteurs de recherche. Le LCP est désormais nettement plus convivial, car l'intention de l'utilisateur est prise en compte. En effet, celui-ci s'intéresse en premier lieu au contenu principal de la page web.

 

Si tu regardes ta métrique, tu te demanderas : quelle est la bonne valeur pour mon LCP ? Google donne les indications suivantes :

 

• Bon : vitesse de chargement inférieure à 2,5 secondes
• Améliorable : vitesse de chargement entre 2,5 et 4 secondes
• Mauvais : vitesse de chargement supérieure à 4 secondes

 

Tu apprendras également dans notre article comment améliorer les Core Web Vitals comme le Largest Contentful Paint.

 

INP : la vitesse de réaction d'un site web

Le Web Vital Interaction to Next Paint est une valeur de mesure de l'interactivité d'un site web. Toutes les actions de l'utilisateur sont enregistrées - c'est-à-dire les clics, les saisies au clavier et les contacts sur les écrans tactiles. On mesure ensuite le temps qui s'écoule avant que la réaction souhaitée soit visible pour l'utilisateur.

 

Un INP faible indique que le site web réagit de manière fluide et rapide pour plus de 75 % des utilisateurs . Cela signifie que les actions sont exécutées en moins de 200 millisecondes. Les valeurs aberrantes ne sont pas prises en compte. Si le temps de réaction est supérieur à 500 millisecondes, l'INP est mauvais, tout ce qui se situe entre 200 et 500 millisecondes peut être amélioré.

 

Pourquoi la mesure INP a-t-elle remplacé le FID Core Web Vital ?

Comme nous l'avons déjà mentionné, l'INP représente une vitalité web assez récente et a remplacé la valeur de mesure FID (First Input Delay) en mars 2024. L'INP a été mis à disposition pour la première fois en 2022 par Google pour être testé. Après son introduction, il est rapidement apparu que ce Web Vital prenait mieux en compte l'expérience utilisateur que le FID. Mais pourquoi en est-il ainsi ?

 

Le First Input Delay ne pouvait illustrer que la première impression d'une page web, car il mesurait exclusivement la première interaction de l'utilisateur. L'INP donne désormais une image beaucoup plus complète de la vitesse de réaction, car il enregistre toutes les interactions de l'utilisateur sur une page web.

 

De plus, l'INP mesure le temps nécessaire pour que le consommateur obtienne une représentation visuelle ou une réaction reconnaissable sur son écran. Cela aussi était différent avec le Web Vital FID. Ce dernier se contentait d'enregistrer le temps nécessaire pour que le navigateur commence à traiter l'interaction. Le FID ne représentait pas le moment où l'utilisateur recevait effectivement une réaction à son action.

 

CLS : la stabilité visuelle d'un site web

Le Cumulative Layout Shift (CLS) est la troisième vitrine web définie par Google pour mesurer l'expérience utilisateur sur un site web. Il s'agit de la stabilité visuelle des blocs de texte, des éléments d'image et des graphiques. Dès que la mise en page se déplace de manière inattendue lors du chargement, du défilement ou d'autres interactions de l'utilisateur, les deux mesures suivantes sont effectuées :

 

1. Quel pourcentage de la zone de représentation l'élément occupe-t-il, y compris le déplacement ? Pour une fraction d'impact de 60 %, la valeur mesurée serait de 0,6.
2. De quelle distance l'élément s'est-il déplacé par rapport à la taille de la zone de représentation ? Avec une fraction de distance de 20 %, la valeur mesurée serait de 0,2.

 

En multipliant les valeurs entre elles, on obtient le Layout Shift Score. S'il est inférieur à 0,1, on parle d'une bonne valeur CLS. Tout ce qui est supérieur est à améliorer. Dans notre exemple, le Layout Shift est de 0,12 (0,6 * 0,2). Il faudrait donc l'optimiser. Timo Specht t'explique maintenant où tu peux trouver les métriques de tes Core Web Vitals.

 

Comment mesurer les Core Web Vitals ?

Les Core Web Vitals sont mesurés par Google aussi bien en ce qui concerne la Mobile Friendliness que pour les versions desktop d'une page. De plus, grâce à leur orientation utilisateur, les valeurs sont faciles à comprendre, même pour les non-initiés.

 

Si tu souhaites maintenant mesurer les Core Web Vitals pour tes sites web, tu te demandes peut-être comment procéder de la manière la plus simple et la plus efficace. Il existe deux méthodes : la collecte de données en laboratoire et la mesure de l'expérience utilisateur réelle. Il est préférable de combiner les deux.

 

Données de laboratoire (Lab Data)

La mesure des données de laboratoire fait appel à des outils qui imitent les accès des utilisateurs à ton site web et mesurent ainsi les Core Web Vitals. Cela est particulièrement utile avant la publication d'une ou de plusieurs pages, afin d'éviter tout problème lié à la véritable expérience de la page.

 

Les outils suivants sont le plus souvent utilisés lors de la collecte de données de laboratoire :

 

• Outils de développement de Chrome(Google Lighthouse)
• Google PageSpeed Insights

 

L'inconvénient des données Lighthouse et autres Lab Data est qu'elles ne constituent pas un facteur de classement et ne sont donc pas pertinentes pour le positionnement dans les résultats des moteurs de recherche. Seules les données de terrain comptent. De plus, le Web Vital INP ne peut pas être mesuré, car il faut pour cela une véritable saisie de l'utilisateur. Une valeur similaire est relevée à la place : TBT (Total Blocking Time). Elle devrait être inférieure à 300 millisecondes.

 

Expériences réelles d'utilisateurs (Field Data)

Les données de laboratoire ne sont pas seulement inintéressantes pour le classement de tes pages dans les SERP, mais elles donnent souvent des résultats différents de ceux des mesures sur le terrain. Cela s'explique par le fait que les utilisateurs utilisent des appareils différentset ont des conditions de réseau différentes.

 

La mémoire vive et les performances du processeur ainsi que les interactions avec le site diffèrent également d'un utilisateur à l'autre et, surtout, d'un utilisateur à l'autre en laboratoire. Contrairement aux mesures effectuées en laboratoire, les données de terrain fournissent donc une image plus réaliste.

 

Pour mesurer l'expérience réelle des utilisateurs, il existe un certain nombre d'outils différents, comme par exemple les outils de mesure d'audience :

 

• Rapport sur l'expérience utilisateur dans Chrome (Google PageSpeed Insights)
• Rapport Google Core Web Vitals
• JavaScript (bibliothèque Web Vitals)
• Extension Web Vitals pour Chrome
• Fournisseurs externes de RUM (Real User Monitoring)

 

Mais les données de terrain ont aussi leurs inconvénients. Ainsi, les nouveaux problèmes sur les sites web ne sont visibles dans les rapports qu'après environ un mois. Pour consulter les indicateurs plus régulièrement, les données de laboratoire peuvent être très utiles. Surtout après des optimisations ou des modifications du site , elles fournissent des informations immédiates sur les effets potentiels sur les Core Web Vitals.

 

Les principaux conseils pour améliorer les Core Web Vitals

Celui qui souhaite améliorer certaines ou toutes les Core Web Vitals doit d'abord trouver la cause d'un mauvais LCP, INP ou CLS. La bonne nouvelle : avec Google PageSpeed Insights, tu peux non seulement consulter les métriques de tous les Core Web Vitals pour tes pages Internet, mais aussi trouver un diagnostic des différents Web Vitals ainsi que des conseils pour les améliorer.

Possibilités d'optimiser le LCP

Le Largest Contentful Paint, c'est-à-dire l'élément le plus important pour l'utilisateur sur ta page, peut être constitué de caractères ou d'un élément d'image. Pour améliorer les temps de chargement, tu dois d'abord déterminer quel élément Google définit comme l'élément principal. Cela peut varier en fonction du terminal de l'utilisateur. Avec PageSpeed Insights, tu dois donc analyser ta page aussi bien pour l'affichage mobile que pour l'affichage desktop.

 

Dans la section Diagnostics, tu trouveras, en plus d'autres conseils utiles pour améliorer tes Web Vitals, l'élément Largest Contentful Paint. Pour améliorer ton temps LCP, cet élément de contenu doit être chargé le plus rapidement possible. Pour cela, tu peux effectuer les réglages suivants dans les systèmes de gestion de contenu comme WordPress:

 

• Configurer le browser cashing pour obtenir une réponse plus rapide du serveur
• Optimiser l'hébergement de ton site web pour un TTFB (Time to First Bite) plus court
• Utiliser le Content Delivery Network pour accélérer la mise à disposition du contenu
• Supprimer/déplacer les JavaScript & CSS inutiles pour un rendu plus rapide des éléments LCP
• Si ton élément LCP est une image, tu devrais la compresser.

 

Même si l'amélioration du LCP peut nécessiter un grand savoir-faire technique, tu dois d'abord te concentrer sur deux choses : Assure un temps de réponse plus rapide de ton serveur et mets l'élément LCP à la disposition de l'utilisateur le plus rapidement possible.

 

Comment obtenir un meilleur INP

Le Web Vital INP peut être mesuré uniquement à l'aide de données de terrain. En règle générale, les données CrUX mises à disposition par Google, que tu trouveras dans le rapport sur l'expérience utilisateur dans Chrome, suffisent à cet effet. Le temps de réaction à l'interaction d'un utilisateur peut alors être affecté aux trois endroits suivants :

 

1. Lors de la saisie (délai de saisie)
2. Lors de la transformation (longue durée de transformation)
3. Lors de la présentation (retard de présentation)

 

Pour accélérer la saisie de l'interaction utilisateur, tu devrais optimiser le code Java Script. Veille à réduire le travail dans le thread principal et à supprimer les codes Java Script tiers inutiles. Les longs travaux de JavaScript devraient en outre être divisés en plusieurs morceaux. Ainsi, les actions de l'utilisateur peuvent avoir lieu entre-temps, sans que JavaScript doive d'abord terminer complètement le travail.

 

Pour un traitement et une présentation plus rapides des contenus, tu dois exclure les problèmes de mise en page en fournissant les contenus de manière asynchrone. Une taille de DOM plus petite contribue également à un rendu plus rapide du contenu des pages.

 

Voici comment tu peux améliorer le CLS

La cause la plus fréquente d'une mesure CLS élevée est le manque d'attribution de la taille des images. Pour que la mise en page se décale moins, tu devrais définir la largeur et la hauteur des éléments dans le code HTML à l'aide de "width" et "height". Ainsi, un espace sera réservé dans la mise en page pour tes images et tes vidéos, même si d'autres éléments ont déjà été chargés auparavant.

 

Pour les annonces publicitaires et les bannières dont tu ne peux pas influencer la taille, tu dois réserver à l'avance un espace suffisamment grand dans la mise en page. Si cela n'est pas possible non plus, les contenus dynamiques doivent être placés plus bas dans la zone d'affichage.

 

Lors de l'utilisation de polices web, des décalages de mise en page peuvent se produire après le chargement de ces polices. Pour éviter cela, l'exploitant du site web peut procéder aux optimisations suivantes :

 

• Sorg dafür, dass die Webschriftart so früh wie möglich lädt (<link rel=preload>).
• Utilise une police de repli dont la taille et le style sont similaires à ceux de la police web.
• Adapte la police Fallback et la police Web à l'aide d'API.
• Réduire le temps de chargement de la police web grâce à la Font Loading API.

 

Pour savoir si les optimisations ont porté leurs fruits, consultez le rapport sur l'expérience utilisateur de Google Chrome après 28 jours.

 

De bons Core Web Vitals et de mauvais classements SERP ? C'est peut-être la raison !

Les Core Web Vitals sont l'une des rares possibilités de rendre la convivialité d'un site web mesurable et comparable en chiffres . Malgré cela, il se peut que ton site ne se positionne pas dans les meilleurs résultats des moteurs de recherche malgré des Web Vitals optimisés. Note que d'autres facteurs de classement contribuent également à l'expérience utilisateur et donc à un meilleur classement sur Google.

 

Une bonne SEO comprend également l'optimisation on-page, qui est obtenue par exemple par des mesures de link building, un design attrayant, des optimisations de mots-clés et un contenu pertinent avec une valeur ajoutée. Si tu tiens compte de ces points, les Core Web Vitals représentent une chance de gagner quelques places dans les SERPs. Chez Timo Specht, nous t'aidons à améliorer globalement tes mesures SEO et SEA et à placer tes pages web au premier rang de Google.