Signaux Web essentiels : Comment améliorer l’expérience utilisateur ?

Les Signaux Web essentiels en bref

Les Signaux Web essentiels (Core Web Vitals) permettent de mesurer l’expérience de l’utilisateur avec une page.

Il en existe trois :

1. LCP – Largest Contentful Paint
2. FID – First Input Delay
3. CLS – Cumulative Layout Shift

Si les données recueillies sur le terrain montrent que les pages obtiennent un score “bon” pour les trois Signaux Web essentiels, elles réussissent l’évaluation de ces signaux.

Depuis la mi-juin 2021, Google a commencé à utiliser les Signaux Web essentiels comme signal de classement.

Mais ce n’est pas fini, ce n’est qu’un début. L’importance des Signaux Web essentiels ne fera que croître à l’avenir.

Dans cet article, nous vous expliquons comment mesurer, interpréter et améliorer vos indicateurs de performance Web afin d’offrir une meilleure expérience aux utilisateurs et, en fin de compte, de gagner plus d’argent !

Table des matières

• Qu’est-ce que le Core Web Vitals ?
• Pourquoi s’intéresser aux Signaux Web essentiels?
• Les Signaux Web essentiels en détail
• Comparer des pommes avec des pommes
• Outils de mesure de Core Web Vitals
• Comment votre score de performance Lighthouse est-il calculé ?
• L’avenir de Core Web Vitals
• Questions fréquemment posées sur Core Web Vitals

Les Signaux Web essentiels (Core Web Vitals) sont un sujet brûlant au sein de la communauté des référenceurs.

Et pour cause : leur amélioration permet d’améliorer l’expérience de l’utilisateur, et elles constituent désormais un facteur de classement pour Google Search dans le cadre des nouveaux signaux d’expérience de la page.

Le déploiement progressif a commencé à la mi-juin 2021 et s’est achevé le 2 septembre 2021.

Pour réussir l’évaluation des Signaux Web essentiels, vous devez obtenir un score “bon” pour les trois Signaux Web essentiels -Largest Contentful Paint (LCP), First Input Delay (FID) et Cumulative Layout Shift (CLS) – en vous basant sur des données de terrain.

La différence entre les données de terrain et les données de laboratoire

Tout au long de cet article, nous parlerons fréquemment de données de terrain et de données de laboratoire.

Ces notions étant souvent mal comprises, il convient d’expliquer tout de suite la différence :

1. Les données de terrain sont recueillies auprès d’utilisateurs réels par l’intermédiaire du rapport sur l’expérience utilisateur de Chrome (“CrUX”).
2. Les données de laboratoire sont recueillies dans un environnement contrôlé, sans aucune participation des utilisateurs réels.

Maintenant que nous avons fait le tour de la question, quelle est la place des Signaux Web essentiels dans les algorithmes de classement de Google ?

Google utilise ces données pour évaluer l’expérience de l’utilisateur en fonction de la présence ou non d’un site :

1. est adapté aux mobile
2. offre HTTPS
3. est exempt de publicités interstitielles intrusives

À ces trois facteurs, ils en ont ajouté un quatrième – Core Web Vitals – et, ensemble, ils forment un groupe de signaux que Google utilise pour évaluer l'”expérience de la page“, comme le montre cette illustration pratique :

Il est important de noter que les Signaux Web essentiels, qu’il s’agisse de données de terrain ou de données de laboratoire, seront une cible mouvante : ils sont un moyen de mesurer l’expérience de l’utilisateur, et comme le Web et ses utilisateurs évoluent constamment, il est tout à fait naturel que les Signaux Web essentiels évoluent eux aussi.

Qu’est-ce que les “Core Web Vitals” ?

Nous vous entendons déjà réciter dans votre tête la célèbre citation de Top Gun “I feel the need… the need for speed !”, mais les mesures des Signaux Web essentiels ne se limitent pas à la vitesse.

Les Signaux Web essentiels sont un ensemble de paramètres relatifs à la vitesse, à la réactivité et à la stabilité visuelle, destinés à aider les propriétaires de sites à mesurer l’expérience de l’utilisateur sur le web.

Les Web essentiels sont divisés en deux catégories : les Signaux Web essentiels et les Signaux Web non-essentiels.

Les principaux Signaux Web essentiels sont les suivants

• Largest Contentful Paint (LCP)
• First Input Delay (FID)
• La métrique INP remplacera FID dès mars 2024.
• Cumulative Layout Shift (CLS)

Et les Signaux Web non-essentiels sont les suivants :

• Total Blocking Time (TBT)
• First Contentful Paint (FCP)
• Speed Index (SI)
• Time to Interactive (TTI)

Chaque indicateur mesure la “qualité” d’une partie de l’expérience de la page.

L’illustration ci-dessous montre comment une page se charge et où les différentes mesures entrent en jeu :

Mais avant de toutes les passer en revue, nous devons d’abord expliquer: pourquoi les Signaux Web essentiels sont importants?

En effet, nous voulons que vous disposiez de toutes les munitions nécessaires pour présenter un dossier solide comme le roc lorsque vous vous adressez à la direction ou au client et de leur soumettre l’amélioration des Signaux Web essentiels d’un site.

Pourquoi s’intéresser aux Signaux Web essentiels ?

Voici les trois principales raisons pour lesquelles vous devriez vous intéresser aux Signaux Web essentiels:

1. 1. Les visiteurs aiment les sites rapides qui sont faciles et agréables à utiliser, sur n’importe quel appareil et depuis n’importe quel endroit. En résumé, vous gagnerez plus d’argent si vous offrez une excellente expérience à vos utilisateurs.
   2. Comme nous l’avons mentionné dans l’introduction, les Signaux Web essentiels sont devenus un facteur de classement à partir de la mi-juin 2021. Bien que nous ne nous attendions pas à voir un grand changement tout de suite et que la pertinence reste beaucoup plus importante, nous nous attendions à ce que son importance augmente avec le temps.
   3. Si vous réussissez l’évaluation des Signaux Web essentiels, il est probable que moins d’utilisateurs se replieront vers les SERP, car vous offrez une bonne expérience à l’utilisateur – et Google a laissé entendre qu’il pourrait commencer à afficher un badge “Bonne expérience de la page” dans ses résultats de recherche. Nous appelons cela des “facteurs de classement indirects”, car ils influencent le comportement des internautes (par exemple, plus de clics pour les pages dotées de ce badge), ce qui se répercute sur les algorithmes de Google. En février 2021, JR Oakes fouillait dans le code frontal de la Search Console de Google lorsqu’il a remarqué que Google avait peut-être déjà fait quelques préparatifs dans ce domaine :

Et supposons que, même si l’impact des Signaux Web essentiels en tant que signal de classement est probablement exagéré, vous constaterez un retour sur investissement pour toute amélioration de l’expérience utilisateur, car une meilleure expérience utilisateur se traduit par des visiteurs plus satisfaits et davantage de conversions

Approfondissez vos connaissances à l’aide de ces ressources :

• Cloudflare a rassemblé plusieurs études de ce type (s’ouvre dans un nouvel onglet) concernant des sites qui montrent comment des millisecondes peuvent avoir un impact sur les taux de rebond, les taux de conversion et, en fin de compte, sur vos résultats.
• Il y a 15 ans, Amazon a appris que son chiffre d’affaires augmentait de 1 % pour chaque diminution de 100 ms du temps de chargement.

Astuce Graines de Référenceur

Google a longtemps essayé de promouvoir la vitesse des pages via Pagespeed Insights et AMP. Et maintenant, avec Core Web Vitals, il est vraiment devenu inséparable du référencement.

L’optimisation de la vitesse des pages est comme n’importe quelle autre partie du SEO – une amélioration seule peut ne pas donner de résultats, mais après avoir fait plusieurs améliorations, vous verrez un coup de pouce dans votre performance SEO.

Pour nous, ce sont les cas extrêmes qui rendent la niche de la vitesse des pages intéressante.

Par exemple, nous avons remarqué que des boutiques en ligne dont le chiffre d’affaires s’élevait à un million de dollars et qui plaçaient des tests A/B après leur feuille de style ont doublé le « First Contentful Paint ».

C’est simplement dû à la façon dont les navigateurs fonctionnent. Et l’agrandissement de « l’image héros » améliorera en fait votre plus grand tableau de contenu, peut-être de 50 % d’après les données du laboratoire.

Les Signaux Web essentiels en détails

Sans plus attendre, plongeons dans chacun des métriques des Signaux Web essentiels :

Largest Contentful Paint (LCP)

Le « Largest Contentful Paint » (LCP) est une caractéristique essentielle du web qui mesure le temps en secondes entre le début du chargement de la page et le moment où le bloc de texte ou l’élément d’image le plus grand est affiché à l’écran.

Son objectif est de mesurer le moment où le contenu principal de la page a fini de se charger.

Plus le LCP est bas, mieux c’est. Un LCP rapide rassure les utilisateurs sur l’utilité d’une page, car il s’agit d’un indicateur qui mesure la vitesse de chargement perçue.

L’indice LCP est disponible à la fois pour les données de terrain et les données de laboratoire.

Sur le terrain, le navigateur cesse de signaler de nouveaux candidats LCP dès que l’utilisateur interagit avec la page (en tapotant, en faisant défiler la page, en appuyant sur une touche, en changeant d’onglet ou en fermant l’onglet).

En laboratoire, le moment où le LCP est terminé n’est pas tout à fait clair. Nous pensons que ce moment survient lorsque la page approche du temps d’interaction (TTI) et qu’il est clair que l’élément est le dernier candidat au LCP.

Considérations importantes

Pendant le chargement d’une page, le bloc de texte ou l’élément d’image le plus grand peut changer, et c’est le candidat le plus récent qui est utilisé pour mesurer le LCP.

Prenons l’exemple d’un titre H1 qui, au départ, est le plus grand bloc de texte, mais qui, par la suite, est remplacé par une image plus grande. L’image la plus grande est alors le candidat principal pour la mesure du LCP.

Veuillez noter que les éléments <svg> ne sont actuellement pas considérés comme des candidats au Largest Contentful Paint.

Ainsi, si vous chargez un gros logo en tant qu’élément <svg>, il ne sera pas considéré comme un candidat au LCP. Cette décision a été prise dans un souci de simplicité et pourrait être modifiée à l’avenir.

Il n’est pas certain que les éléments <video>; soient actuellement considérés comme des candidats LCP ; nous avons contacté Google pour obtenir des éclaircissements.

Astuce Grianes de Référenceur

La première question à se poser lorsque l’on cherche à optimiser son LCP est la suivante : Quel devrait être l’élément de mon LCP ?

Lorsque je travaille sur l’optimisation des LCP, je constate que, dans la plupart des cas, l’élément LCP n’est pas le contenu le plus important de la page.

Il s’agit plutôt d’une bannière de consentement aux cookies ou d’une bannière/modale promotionnelle. Ces éléments reflètent-ils le contenu utile ? Non !

La première étape consiste donc à noter les candidats LCP les plus éligibles pour chaque type de page. Par exemple, pour un article de blog, il peut s’agir du h1, de l’image de couverture et du premier paragraphe de l’article.

Pour une page de détails sur un produit, il peut s’agir de l’image du produit, de son nom et de son prix. Vous pouvez remplir un tableau répertoriant tous les types de pages candidats LCP et en discuter avec l’équipe.

La deuxième étape consiste ensuite à classer par ordre de priorité les éléments de nos candidats LCP. L’objectif est de les afficher le plus rapidement possible.

Comment interpréter le score LCP?

Voici comment interpréter le score LCP :

• • Bon : <= 2.5s (2.5 secondes ou moins)
  • Amélioration nécessaire : > 2,5s <= 4s (entre 2,5 et 4 secondes)
  • Mauvais : > 4s (plus de 4 secondes)

Quelles sont les causes d’un mauvais score au LCP ?

Les causes d’un mauvais score LCP peuvent être multiples :

• • temps de réponse lent du serveur,
  • JavaScript et CSS bloquant le rendu,
  • ressources de contenu trop lourdes nécessitant un temps de chargement trop long, etc.

Astuce Graines de Référenceur

L’amélioration de l’indicateur Largest Contentful Paint est l’un des indicateurs Core Web Vitals les plus difficiles à résoudre, car il existe un large éventail de facteurs susceptibles de l’affecter.

L’étude des temps de réponse initiaux du serveur est un bon moyen d’évaluer si vous avez des problèmes d’infrastructure sous-jacents susceptibles d’affecter le time to first byte (TTFB), et donc d’avoir un impact sur les scores LCP.

Pour connaître votre niveau de référence initial, trouvez (ou créez) une page HTML vierge / statique, ce qui signifie généralement qu’il n’y a pas de traitement côté serveur avant que la page puisse être affichée, et utilisez cette URL pour l’exécuter avec l’outil de mesure de votre choix.

Si cette page statique présente toujours un temps de réponse initial du serveur élevé, cela signifie que vous devez peut-être vous pencher sur l’infrastructure du site – en mettant à niveau votre plateforme d’hébergement et en envisageant l’utilisation d’un CDN pour améliorer les scores sur l’ensemble du site – ou qu’il peut s’agir d’un pare-feu ou d’un paramètre DNS.

Ce processus vous permettra également d’obtenir un chiffre de référence, c’est-à-dire le chiffre le plus bas auquel vous pouvez vous attendre si aucune amélioration n’est apportée au serveur.

Comment améliorer le score LCP ?

Vous pouvez faire beaucoup de choses pour améliorer votre score LCP, par exemple optimiser votre chemin de rendu critique, votre CSS et vos images. Les décrire toutes dépasse largement le cadre de cet article. Nous vous recommandons donc de consulter les ressources de web.dev sur l’optimisation des scores LCP (s’ouvre dans un nouvel onglet).

Astuce Graines de Référenceur

Une TTFB importante peut vraiment aggraver les problèmes de LCP, mais il y a une chose à laquelle il faut faire attention lorsque l’on signale des problèmes de TTFB aux développeurs :

L’audit Lighthouse utilisé par PageSpeed Insights et GTMetrix (sur les paramètres mobiles par défaut) ajoute une latence artificielle à toute interaction avec le serveur, ce qui signifie que quelque chose avec de multiples handshakes comme TTFB peut sembler bien pire lorsque le taux est limité.

Pour tester le TTFB sans utiliser d’outil tiers, vous pouvez utiliser l’outil de ligne de commande cURL et l’argument -- write-out/-w, par exemple : curl -w "%{time_starttransfer}\n" https://www.exemple.com -o /dev/null

La métrique INP remplacera FID dès mars 2024.

First Input Delay (FID)

Le First Input Delay (FID) est une caractéristique essentielle du web qui mesure le temps en millisecondes entre le moment où un utilisateur interagit pour la première fois avec votre site (c’est-à-dire lorsqu’il clique sur un lien, appuie sur un bouton ou sur une touche) et le moment où le navigateur est en mesure de répondre à cette interaction.

Le FID est à la base de la première impression qu’a l’utilisateur de l’interactivité et de la réactivité de votre site. Mieux vaut que ce soit une bonne impression !

Comme le suggère la description de cette mesure, elle ne peut être mesurée que sur le terrain, car elle repose sur l’interaction avec l’utilisateur.

Par conséquent, le FID n’est disponible que dans les données de terrain. Plus le FID est faible, mieux c’est.

Pour les tests en laboratoire, on utilise le Total Blocking Time (TBT), qui est étroitement lié au First Input Delay.

Considérations importantes

Le FID ne mesure pas le temps nécessaire au navigateur pour traiter un événement (par exemple, une pression sur un bouton), ni le temps nécessaire pour mettre à jour l’interface utilisateur par la suite.

Les interactions telles que le défilement et le zoom ne sont pas considérées comme des actions, car elles sont continues par nature et ont des contraintes de performance très différentes, car l’action de défilement est exécutée par le GPU au lieu du CPU, ou par le compositor thread du CPU au lieu du main thread.

Comment interpréter le score FID?

Voici comment interpréter votre score FID :

• • Bon : <= 100ms
  • Amélioration nécessaire : > 100 ms et <= 300 ms
  • Mauvais : > 300 ms

Quelles sont les causes possibles d’un mauvais score FID ?

L’une des raisons les plus courantes d’un mauvais score FID est que le fil principal d’un navigateur  est occupé à analyser et à exécuter le code JavaScript.

Lorsque le fil principal est occupé, il ne peut pas encore répondre à l’interaction de l’utilisateur.

Comment améliorer le score FID?

Si vous souhaitez améliorer votre score FID, vous devez examiner de près ce qui empêche le navigateur d’être interactif.

Voici quelques exemples de mesures que vous pouvez prendre pour améliorer votre score FID :

• • Réduction du temps d’exécution de JavaScript.
  • Minimiser le travail effectué dans le fil principal.
  • Réduire l’impact du code tiers.

La description des tenants et aboutissants de l’amélioration de votre score FID dépasse le cadre de cet article.

Nous vous recommandons donc de consulter les ressources de web.dev sur l’optimisation des scores FID (s’ouvre dans un nouvel onglet).

Interaction to Next Paint (INP)

L’INP, abréviation d’Interaction to Next Paint, représente une mesure évaluant la réactivité, c’est-à-dire la capacité d’une page Web à réagir rapidement aux interactions des utilisateurs.

INP évalue cette réactivité à l’aide des données de l’API Event Timing. Lorsqu’une interaction fait qu’une page ne répond plus, l’expérience de l’utilisateur est médiocre.

Pour ce faire, il observe le délai entre les clics, tapotements et saisies au clavier pendant toute la durée de la visite d’un utilisateur sur une page.

La valeur finale de l’INP est établie en prenant en compte la durée de la plus longue interaction, en excluant les valeurs extrêmes qui pourraient fausser les résultats.

Les données d’utilisation de Chrome montrent que 90 % du temps passé par un utilisateur sur une page est passé après le chargement de celle-ci. C’est ce que la mesure INP évalue.

Une bonne réactivité signifie qu’une page répond rapidement aux interactions qu’elle subit. Lorsqu’une page répond à une interaction, il en résulte un retour d’information visuel, présenté par le navigateur dans le cadre suivant.

Le retour d’information visuel vous indique, par exemple, si un article que vous ajoutez à un panier d’achat en ligne est effectivement ajouté, si un menu de navigation mobile s’est ouvert, si le contenu d’un formulaire de connexion est authentifié par le serveur, et ainsi de suite.

Certaines interactions prendront naturellement plus de temps que d’autres, mais pour les interactions particulièrement complexes, il est important de présenter rapidement un premier retour d’information visuel pour signaler à l’utilisateur que quelque chose est en train de se passer. Le temps qui s’écoule jusqu’à la prochaine peinture est la première occasion de le faire.

Par conséquent, l’objectif de l’INP n’est pas de mesurer tous les effets éventuels de l’interaction (tels que les recherches sur le réseau et les mises à jour de l’interface utilisateur à partir d’autres opérations asynchrones), mais le temps pendant lequel la peinture suivante est bloquée. En retardant le retour visuel, vous pouvez donner aux utilisateurs l’impression que la page ne réagit pas à leurs actions.

L’objectif de l’INP est de faire en sorte que le délai entre le moment où l’utilisateur lance une interaction et le moment où la prochaine image est peinte soit le plus court possible, pour toutes les interactions de l’utilisateur ou pour la plupart d’entre elles.

Prenons l’exemple d’un retour visuel immédiat sur l’ouverture d’un accordéon : une mauvaise réactivité peut entraîner de multiples réponses involontaires aux saisies parce que l’utilisateur pense que l’expérience est interrompue.

Qu’est-ce qu’une interaction ?

Une interaction est un groupe d’événements qui se déclenchent au cours du même geste logique de l’utilisateur. Par exemple, quand vous appuyez sur un écran tactile, cela inclut plusieurs actions comme bouger le doit vers le haut (le pointeur vers le haut), ensuite vers le bas (le pointeur vers le bas) et enfin vous appuyer (le clic).

Une interaction peut être pilotée par JavaScript, CSS, des contrôles intégrés au navigateur (tels que des éléments de formulaire) ou une combinaison de ces éléments.

La réactivité ou la latence d’une interaction correspond à la durée la plus longue, depuis le moment où l’utilisateur commence à appuyer sur une page pour une action déterminée jusqu’au moment où l’image suivante est présentée avec un retour visuel.

Les interactions peuvent être décomposées en trois phases :

• Le délai d’entrée, qui commence lorsque l’utilisateur initie une interaction avec la page et se termine lorsque les rappels d’événements pour l’interaction commencent à s’exécuter.
• Le délai de traitement, qui correspond au temps nécessaire pour que les rappels d’événements soient exécutés jusqu’à leur terme.
• Le délai de présentation, qui est le temps nécessaire au navigateur pour présenter l’image suivante qui contient le résultat visuel de l’interaction.

La somme de ces trois phases correspond à la latence totale de l’interaction. Chaque phase d’une interaction contribue, dans une certaine mesure, à la latence totale de l’interaction.

Remarques

En ce qui concerne l’INP, seuls les types d’interaction suivants sont observés :

• • Cliquer avec une souris.
  • Taper sur un appareil doté d’un écran tactile.
  • Appuyer sur une touche d’un clavier physique ou d’un clavier à l’écran.

Le survol et le défilement ne sont pas pris en compte dans l’INP.

Toutefois, le défilement à l’aide du clavier (barre d’espacement, page précédente, page suivante, etc.) implique une frappe de touche, qui peut déclencher d’autres événements mesurés par l’INP. Le défilement qui en résulte n’est pas pris en compte dans le calcul de l’INP.

Les interactions se produisent dans le document principal ou dans des iframes intégrées au document, par exemple en cliquant sur la lecture d’une vidéo intégrée.

Considérations importantes

Comme indiqué ci-dessus, l’INP est calculé en observant toutes les interactions effectuées avec une page. Pour la plupart des sites, c’est l’interaction présentant la plus mauvaise réactivité qui est signalée comme INP.

Toutefois, pour les pages comportant un grand nombre d’interactions, des problèmes aléatoires peuvent entraîner une interaction anormalement élevée sur un site par ailleurs réactif. Plus le nombre d’interactions est élevé, plus ce phénomène est susceptible de se produire.

Pour contrer ce phénomène et donner une meilleure mesure de la réactivité réelle de ces types de pages, c’est l’interaction la plus faible qui sera prise en compte.

Quelle est la différence entre INP et FID ?

L’INP prend en compte toutes les interactions de la page alors que le FID ne tient compte que de la première interaction et du délai de saisie de la première interaction en d’autres mots il ne comptabilise pas le délai de présentation de l’image suivante.

Le FID est également une mesure de la réactivité au chargement c’est-à-dire à la première bonne impression de l’utilisateur.

Le raisonnement est que si la première interaction avec une page dans la phase de chargement a un délai d’entrée peu ou pas perceptible, la page a fait une bonne première impression.

INP ne se limite pas à la première impression. En comparant toutes les interactions, la réactivité peut être évaluée de manière complète, ce qui fait de l’INP un indicateur plus fiable de la réactivité globale que le FID.

Comment interpréter le score INP?

Voici comment interpréter votre score INP :

• Bon : <= 200ms
• Amélioration nécessaire : > 200 ms et <= 500 ms
• Mauvais : > 500 ms

Comment déterminer les causes d’un mauvais INP ?

La meilleure façon de mesurer l’INP de votre site web ou d’une page web est de recueillir des données auprès d’utilisateurs réels sur le terrain issues du Real User Monitoring (RUM).

En contexte de laboratoire, L’idéal serait d’amorcer les essais en laboratoire dès que des données concrètes provenant du terrain laissent entrevoir des interactions de nature lente.

Néanmoins, en l’absence de données issues du terrain, diverses stratégies permettent de reproduire ces interactions lentes au sein du laboratoire.

Ces approches englobent notamment le suivi des parcours empruntés généralement par les utilisateurs ainsi que l’évaluation des interactions en cours de leur cheminement.

De plus, il serait recommandé d’interagir avec la page lors de sa phase de chargement – période où le thread principal est souvent le plus sollicité – dans le but de mettre en lumière les interactions lentes qui se manifestent pendant cette étape cruciale de l’expérience utilisateur.

Quelles sont les causes possibles d’un mauvais score INP ?

L’une des raisons les plus courantes d’un mauvais score FID est que le fil principal d’un navigateur  est occupé à analyser et à exécuter le code JavaScript.

Lorsque le fil principal est occupé, il ne peut pas encore répondre à l’interaction de l’utilisateur.

Comment améliorer le score INP?

Si vous souhaitez améliorer votre score INP, vous devez examiner de près ce qui empêche le navigateur d’être réactif.

Voici quelques exemples de mesures que vous pouvez prendre pour améliorer votre score INP :

• • Réduction du temps d’exécution de JavaScript.
  • Minimiser le travail effectué dans le fil principal (peut-être en raison du chargement, de l’analyse et de la compilation des scripts).
  • Réduire l’impact du code tiers.

La métrique FID est utilisée jusqu’à février 2024.

Cumulative Layout Shift (CLS)

Le Cumulative Layout Shift (CLS) est une caractéristique essentielle du Web qui mesure le score cumulé de tous les décalages inattendus de la mise en page à l’intérieur de la fenêtre qui se produisent pendant le cycle de vie complet d’une page.

Son objectif est de mesurer la “stabilité visuelle” d’une page, qui influence fortement l’expérience de l’utilisateur.

CLS est disponible à la fois en données de terrain et en données de laboratoire. Plus le score CLS est bas, meilleure est la stabilité visuelle.

Le CLS n’est pas mesuré en secondes comme la plupart des autres mesures. Il part de la taille de la fenêtre, se rapporte aux éléments qui se déplacent entre deux cadres – appelés éléments instables – et mesure leur déplacement dans la fenêtre.

Le score de décalage de la mise en page est le produit de deux composantes : la “fraction d’impact” et la “fraction de distance”.

La “fraction d’impact” est la zone de la fenêtre que l’élément instable occupe dans les deux images :

La “fraction de distance” est la plus grande distance que l’élément instable parcourt entre les deux images, divisée par la plus grande dimension de la fenêtre de visualisation (largeur ou hauteur) :

Voici plusieurs exemples qui vous permettront de mieux comprendre le mode de calcul du CLS (s’ouvre dans un nouvel onglet).

Considérations importantes

Le cycle de vie complet d’une page signifie que lorsque la page reste ouverte pendant des jours, voire des semaines, le CLS est mesuré pendant toute cette période.

Il est évident que c’est là que les données de terrain du CLS et les données de laboratoire présenteront des différences, car les outils ne recueillent les données de laboratoire que pendant une très courte période.

Il peut s’avérer difficile de tester correctement les changements de présentation inattendus dans les environnements de test, car certaines fonctionnalités peuvent être désactivées ou fonctionner différemment.

Quelques exemples : les notifications de cookies peuvent ne pas s’afficher, l’assistance par chat en direct peut être désactivée et le contenu personnalisé ne sera pas chargé.

Comment interpréter votre score CLS

Voici comment interpréter votre score CLS :

• • Bon : <= 0,1
  • Amélioration nécessaire : > 0,1 <= 0,25
  • Médiocre : > 0,25

Quelles sont les causes possibles d’un mauvais score au CLS ?

Les modifications inattendues, de la mise en page, sont souvent dues à des images ou des publicités dont:

• • les dimensions ne sont pas définies,
  • à des ressources chargées de manière asynchrone et
  • à des situations dans lesquelles de nouveaux éléments DOM sont ajoutés de manière dynamique à une page, au-dessus du contenu existant qui a déjà été chargé.

Le contenu déjà chargé est alors repoussé.

Astuce Graines de Référenceur

Lorsque nous vérifions le CLS pour le site web d’un client, nous examinons toujours l’enregistrement des performances dans Chrome DevTools pour repérer les changements de mise en page sur une page.

Sous l’onglet Performance, nous nous assurons que les Captures d’écran et les Signaux Web essentiels sont activés et nous commençons le profilage en appuyant sur le bouton de préchargement.

Une fois cette étape terminée, la section Expérience (qui ne s’affiche que s’il y a des changements de disposition) révèle les occurrences exactes des changements de disposition, sous la forme de blocs rouges.

Lorsque l’on sélectionne ces blocs, on obtient des informations utiles (dans l’onglet Résumé), notamment le nœud connexe qui a subi le changement et son score cumulé.

Les captures d’écran affichées en haut du profil de performance peuvent également fournir une visualisation utile des éléments ayant subi un décalage

Comment améliorer le score CLS ?

Vous pouvez éviter les changements de mise en page inattendus, par exemple en incluant toujours des attributs de taille pour vos images et vos vidéos et en n’insérant pas de contenu au-dessus d’un autre contenu déjà chargé.

Nous vous recommandons de consulter l’article de web.dev sur l’optimisation des scores CLS (s’ouvre dans un nouvel onglet) pour connaître l’ensemble des améliorations que vous pouvez apporter.

En savoir plus sur CLS

• Le cycle de vie d’une page expliqué (ouvre un nouvel onglet – en anglais)

Total Blocking Time (TBT)

Le Total Blocking Time (TBT) est un Signal Web non-essentiel qui mesure le temps total en millisecondes entre la First Contentful Paint (FCP) et le Time to Interactive (TTI) pendant lequel le thread principal est bloqué suffisamment longtemps pour ne pas réagir aux entrées de l’utilisateur.

Le TBT est en corrélation étroite avec le First Input Delay (FID) et est donc considéré comme la meilleure alternative lorsque les tests sont effectués dans un environnement de laboratoire où l’interaction réelle avec l’utilisateur n’est pas possible.

Bien que le TBT puisse être recueilli sur le terrain, il est facilement influencé par l’interaction de l’utilisateur et ne constitue pas une mesure fiable pour évaluer le temps qu’il faut à une page pour devenir réactive à l’entrée de l’utilisateur.

C’est pourquoi le TBT n’est utilisé que pour les données de laboratoire.

Toute tâche dont l’exécution prend plus de 50 ms est considérée comme une tâche longue, et le temps qui s’ajoute aux 50 ms est considéré comme le “temps de blocage”.

Le TBT est calculé en faisant la somme des temps de blocage de toutes les tâches longues.

Par exemple, s’il y a trois tâches longues :

1. 1. La tâche A prend 75 ms (25 ms de plus que 50 ms).
   2. La tâche B dure 60 ms (10 ms de plus que 50 ms).
   3. La tâche C prend 85 ms (35 ms de plus que 50 ms).

Le TBT est alors de 70ms (25+10+35). Plus le TBT est bas, mieux c’est.

Comment interpréter le score TBT ?

Voici comment interpréter votre score TBT :

• Bon : <= 200ms
• Amélioration nécessaire : > 200ms <= 600ms
• Mauvais : > 600 ms

Causes d’un mauvais score TBT et comment l’améliorer ?

Les sections Améliorer votre score FID ci-dessus et Comment améliorer votre score TBT (s’ouvre dans un nouvel onglet) expliquent en détail les causes d’un mauvais score TBT et comment l’améliorer.

First Contentful Paint (FCP)

Le First Contentful Paint (FCP) est un Signal Web non-essentiel qui mesure le temps écoulé entre le début du chargement d’une page et le moment où une partie du contenu de cette page est affichée à l’écran.

Le fait d’avoir un FCP rapide rassure les utilisateurs sur le fait qu’il se passe quelque chose.

Dans ce contexte, le contenu désigne le texte, les images (y compris les images d’arrière-plan), les éléments <svg> et les éléments <canvas> non blancs.

Le FCP est disponible à la fois dans les données de terrain et dans les données de laboratoire, et plus le FCP est bas, mieux c’est.

Comment interpréter le score FCP ?

Voici comment interpréter votre score FCP :

• Bon : <= 1.8s
• Amélioration nécessaire : > 1.8s <= 3s
• Médiocre : > 3s

Quelles sont les causes possibles d’un mauvais score au FCP ?

Les causes courantes d’un mauvais score au FCP sont des temps de réponse élevés du serveur et des ressources bloquant le rendu.

Comment améliorer le score au FCP ?

Vous pouvez faire beaucoup de choses pour améliorer votre score FCP, par exemple éliminer les ressources bloquant le rendu, supprimer les feuilles de style CSS inutilisées, minifier les feuilles de style CSS et utiliser un CDN.

Le sujet de l’amélioration de votre score FCP mérite vraiment un article à part entière.

En attendant, nous vous recommandons vivement de consulter les ressources de web.dev sur l’optimisation des scores FCP (s’ouvre dans un nouvel onglet).

Speed Index (SI)

Le Speed Index (SI) est un Signal Web non-essentiel qui mesure la rapidité avec laquelle le contenu d’une page est visiblement rempli pendant le chargement de la page.

Il est calculé à l’aide d’une analyse image par image du comportement de chargement de votre page, en comptant la progression visuelle entre les images capturées toutes les 100 ms.

Le SI est disponible à la fois pour les données de terrain et les données de laboratoire.

Comment interpréter le score SI ?

Voici comment interpréter votre score SI :

• Bon : <= 3.4s
• Amélioration nécessaire : > 3.4s <= 5.8s
• Médiocre : > 5,8 s

Quelles sont les causes possibles d’un mauvais score SI ?

Tout ce qui empêche la page de se charger rapidement nuit à votre score SI.

Certaines des causes mentionnées pour les autres indicateurs, comme par exemple le blocage du fil de discussion principal, s’appliquent également ici.

Comment améliorer le score SI ?

Si vous vous concentrez sur l’amélioration des performances globales de chargement des pages, vous verrez votre score SI s’améliorer également.

Nous vous recommandons de consulter la ressource de web.dev à ce sujet ici (s’ouvre dans un nouvel onglet).

Time to Interactive (TTI)

Le Time To Interactive (TTI) est un Signal Web non-essentiel qui mesure le temps écoulé entre le moment où la page commence à se charger et celui où elle est totalement interactive.

Pour qu’il soit pleinement interactif, il doit.. :

1. 1. Afficher un contenu utile (mesuré par First Contentful Paint).
   2. Les éléments les plus visibles de la page sont rendus.
   3. Répondre aux interactions de l’utilisateur dans un délai de 50 ms.

Bien qu’il soit possible de mesurer le TTI sur le terrain, ce n’est pas recommandé, car l’interaction de l’utilisateur peut fortement influencer le TTI de votre page.

Par conséquent, vous ne devriez utiliser le TTI qu’à partir d’un environnement de données de laboratoire.

Comment interpréter le score TTI ?

Voici comment interpréter votre score TTI :

• Bon : <= 3.8s
• Amélioration nécessaire : > 3.8s <= 7.3s
• Médiocre : > 7,3 s

Quelles sont les causes possibles d’un mauvais score TTI ?

Comme pour l’indice de vitesse ci-dessus, de nombreux facteurs à l’origine des mauvais résultats dans les autres indicateurs que nous avons décrits s’appliquent également au TTI, car il s’agit d’un indicateur qui englobe ces autres indicateurs.

Comment améliorer le score TTI ?

Nous vous recommandons de consulter cet article de web.dev (s’ouvre dans un nouvel onglet) pour connaître les prochaines étapes à suivre pour améliorer votre TTI.

Comparer des pommes avec des pommes

Lorsqu’il s’agit des données de Signaux Web essentiel, il est essentiel de comparer des pommes avec des pommes.

C’est pourquoi nous devons souligner les différences entre les données de terrain et les données de laboratoire, ainsi qu’entre les données mobiles et les données de bureau.

Données de terrain et données de laboratoire

Il existe deux types de données :

1. 1. Les données de terrain sont collectées auprès d’utilisateurs réels. Chacun dispose d’un appareil et d’une connexion réseau uniques, grâce au rapport sur l’expérience utilisateur de Chrome (s’ouvre dans un nouvel onglet) (“rapport CrUX” en abrégé).
   2. Les données de laboratoire ne sont pas collectées auprès d’utilisateurs réels. Elles sont collectées dans un environnement contrôlé avec un appareil prédéfini et des paramètres de connexion au réseau.

Il est essentiel que vous compreniez la différence entre ces deux types de données.

Prenez le temps d’y réfléchir, car il s’agit peut-être de l’aspect le plus souvent mal compris des mesures des Signaux Web essentiels.

Vous pouvez obtenir d’excellents résultats dans Lighthouse (données de laboratoire) et vous en féliciter, alors que vos utilisateurs réels ont une expérience médiocre (données de terrain).

Vous pouvez aussi avoir la même situation à l’envers : d’excellents scores basés sur des données de terrain et de mauvais scores basés sur des données de laboratoire !

Ensuite, il y a le “Résumé d’origine”, qui est basé sur des données de terrain représentant l’expérience globale de toutes les pages servies à partir de votre site.

Notez que si vous avez des modèles de pages spécifiques qui se chargent notoirement lentement, cela nuira à votre score de résumé d’origine.

Mesures et disponibilité des Signaux Web essentiel

Voici un aperçu pratique de la disponibilité des mesures des Signaux Web essentiel dans les données de terrain et de laboratoire :

Ce qu’il faut savoir de plus sur les données de terrain

Données de terrain :

• • Peut ne pas être disponible pour vos pages si elles ne reçoivent pas assez de visiteurs, ce qui signifie qu’il n’y a pas assez de données CrUX. Ceci s’applique à la fois aux URL individuelles et à votre résumé d’origine.
  • Est moins utile pour le débogage, car après avoir apporté quelques améliorations, vous devrez attendre que de nouvelles données CrUX arrivent. C’est pourquoi nous recommandons de s’appuyer sur les données du laboratoire à des fins de débogage.
  • Inclut également des données provenant de marchés auxquels vous ne vous adressez pas nécessairement. Par exemple, si vous ciblez principalement les États-Unis, mais que vous recevez beaucoup de trafic des marchés émergents qui n’ont pas le même accès à l’internet rapide et au matériel informatique, vous obtiendrez des données de terrain très hétérogènes, simplement parce que l’audience auprès de laquelle vos données de terrain sont collectées est également très hétérogène.
  • Peut également inclure des données provenant de pages non indexables telles que les pages d’atterrissage PPC (source)(s’ouvre dans un nouvel onglet).

Ce qu’il faut savoir de plus sur les données de laboratoire

Données de laboratoire :

• • Est collecté (à partir d’avril 2021) en émulant un téléphone mobile Moto G4 avec une connexion 3G rapide.
  • Ne comprend pas les données relatives à l’interaction avec l’utilisateur, car les données de laboratoire sont simulées. C’est pourquoi le First Input Delay (FID) n’est pas disponible dans les environnements de laboratoire.
  • Les résultats sont reproductibles, car vous contrôlez le matériel et les paramètres (connexion internet et performance du processeur).

Synthèse des données de terrain et des données de laboratoire

Astuce Graines de Référenceur

Je vous conseille d’examiner autant de données de terrain que possible pour l’analyse initiale afin de mieux comprendre les problèmes qui affectent l’expérience des utilisateurs de votre site.

Une fois que vous aurez acquis suffisamment d’informations à partir des données de terrain, exploitez les données de laboratoire pour les tests et le débogage.

Gardez à l’esprit que les données de laboratoire varieront en fonction de votre connexion internet, de votre appareil, de votre localisation, etc., alors ne vous inquiétez pas si vous obtenez des résultats différents à chaque fois que vous testez votre site.

Communiquer clairement vos conclusions aux autres équipes – des experts UX aux développeurs – est essentiel ici.

Lorsqu’il s’agit d’expérience utilisateur (en particulier sur les grands sites de commerce électronique), vous ne pouvez réussir que si l’ensemble de l’équipe travaille en synergie.

Données mobiles et données de bureau

Vous trouverez des données mobiles, des données de bureau et un mélange des deux lorsque vous rechercherez les scores des Signaux Web essentiel.

Vous pouvez consulter les données de terrain pour les mobiles et les ordinateurs de bureau séparément dans PageSpeed Insights et Google Search Console et en explorant les données CrUX via BigQuery et le CrUX Dashboard(s’ouvre dans un nouvel onglet).

Il est courant de voir les scores de votre ordinateur de bureau être meilleurs que ceux de votre téléphone portable. C’est tout à fait logique, étant donné qu’un appareil de bureau dispose souvent d’un meilleur matériel et d’une connexion internet plus rapide et plus fiable.

Quels Outils de mesure pour les Signaux Web essentiel ?

Maintenant que nous avons expliqué les mesures de l’indicateur des Signaux Web essentiel et les différences entre les données de terrain et les données de laboratoire, ainsi que les données de bureau et les données mobiles, passons en revue les outils les plus populaires et voyons à quoi ressemblent nos Signaux Web essentiel:

1. 1. PageSpeed Insights
   2. web.dev Measure
   3. Google Search Console

PageSpeed Insights (PSI)

L’outil PageSpeed Insights (s’ouvre dans un nouvel onglet) de Google (“PSI” en abrégé) vous permet de soumettre une URL, et il fera alors trois choses :

1. Extraction des données de terrain
2. Collectez des données de laboratoire en exécutant Lighthouse (s’ouvre dans un nouvel onglet).
3. Proposer des améliorations dans les rubriques “Opportunités” et “Diagnostics”.

Nous soumettons à nouveau notre page d’accueil et voici les données de terrain que nous obtenons :

PageSpeed Insights vous indique les données dont il dispose pour votre URL.

Sous les données du champ spécifique à l’URL, nous pouvons choisir d’afficher ou non “Découvrez l’expérience de vos utilisateurs” (il s’agit de l’expérience globale de l’utilisateur de toutes les pages servies à partir de notre site)

Si vous faites défiler la page un peu plus bas, vous verrez les données  :

Astuces Graines de Référenceur

Pour ceux qui effectuent des vérifications ponctuelles et souhaitent utiliser les Chrome DevTools, l’onglet Performance permet de tester et de déboguer les mesures de Web Vitals, telles que Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), First Paint (FP), First Contentful Paint (FCP) et/ou First Meaningful Paint (FMP).

Lorsque vous activez les Captures d’écran et les Vitesses du Web, vous voyez les différentes étapes de l’évolution de votre site pendant le rendu sur un téléscripteur :

web.dev Measure

web.dev Measure(s’ouvre dans un nouvel onglet) était une alternative à PageSpeed Insights.

Lorsque vous soumettiez une URL, Measure indiquera ses Vitesses Web basées sur les données de laboratoire recueillies à l’aide de Lighthouse, dans une interface légèrement plus facile à naviguer.

Désormais, l’outil de mesure est transféré vers PageSpeed Insights. Il a été supprimé en raison du chevauchement important avec PageSpeed Insights.

Google Search Console

Google Search Console fournit des données de terrain pour les ordinateurs de bureau et les appareils mobiles pour toutes vos propriétés vérifiées.

Lorsque vous vous rendez dans Améliorations > Vitaux Web de base, vous trouverez l’écran suivant :

Lorsque vous cliquez sur Ouvrir un rapport pour Mobile ou Desktop, vous obtenez une vue plus détaillée de vos performances Core Web Vitals pour ce type d’appareil.

Si nous cliquons sur Mobile, voici ce que nous voyons :

On dirait que nous nous en sortons plutôt bien !

Cliquez sur l’une des lignes du tableau Détails pour obtenir une vue d’ensemble avec des exemples d’URL.

Les URL que Google considère comme similaires sont regroupées. Pour notre site, par exemple, certains des différents modèles sont regroupés.

Il est logique que Google regroupe ces URL, car elles souffrent souvent des mêmes problèmes qui entravent les performances de chargement des pages.

Résumé des données offertes par les différents outils

Astuce Graines de Référenceur

Lorsque vous savez que Google évalue les performances de toutes les pages de votre site (même les pages non indexables), vous pouvez vous sentir dépassé.

C’est pourquoi l’optimisation des Signaux Web essentiels de votre site nécessite une approche intelligente.

Commencez par les éléments latéraux qui posent problème (par exemple, les icônes dans la navigation qui entraînent des changements de mise en page).

Vous devrez ensuite réfléchir à des modèles : Page d’accueil, pages de catégories, pages de services, pages de produits, blogs, etc. Ils présentent tous des problèmes communs.

En corrigeant un modèle, vous améliorez donc toutes les pages qui utilisent ce modèle.

En outre, une fois l’optimisation effectuée, il est judicieux de créer un processus pour l’ajout de nouveaux éléments/blocs de contenu sur le site web afin qu’ils ne nuisent pas aux performances.

Un bon exemple est l’ajout de tweets via des captures d’écran par rapport à des éléments intégrés : l’une de mes expériences a montré une différence de 11,5 secondes contre 1,9 seconde en JavaScript inutilisé pour un seul tweet intégré que j’ai remplacé par une capture d’écran.

De tels processus contribueront à rendre l’optimisation des Signaux Web essentiels  de base à l’épreuve du temps.

Comment votre score de performance Lighthouse est-il calculé ?

Nous avons abordé en détail les scores des Signaux Web essentiels, mais nous n’avons pas encore abordé la manière dont le score de performance global de Lighthouse est calculé.

Tout d’abord, la note de performance Lighthouse est basée sur des données de laboratoire.

Il s’agit d’une valeur sur une échelle allant de 4 (très mauvais) à 100 (excellent). Il s’agit d’une moyenne pondérée des scores métriques des Signaux Web essentiels, et les scores ne sont pas tous pondérés de la même manière.

Les poids de la version actuelle -version 10- et la version précédente 8/9 sont les suivants :

Note : les Signaux Web essentiels  marquées d’un * sont des Signaux Web essentiels de base.

Remarques importantes :

1. Le score de performance que vous trouverez dans Lighthouse, et dans d’autres outils qui s’appuient sur les données de Lighthouse, est toujours basé sur des données de laboratoire.
2. Dans le tableau ci-dessus, seules deux mesures des Signaux Web essentiels  sont indiquées. Cela s’explique par le fait que la troisième, le First Input Delay, n’est pas mesurable en laboratoire.

Les scores des Signaux Web essentiels sont calculés sur la base de leur performance par rapport aux données réelles de performance des sites web provenant de HTTP Archive(opens in a new tab).

Par exemple : une valeur métrique LCP (Largest Contentful Paint) de 1.220 ms est mise en correspondance avec un score métrique de 99 sur la base des données d’archives HTTP.

Lighthouse utilise ensuite les plages suivantes, codées par couleur, pour “juger” votre score :

• Rouge (mauvais) : 0 à 49
• Orange (à améliorer) : de 50 à 89
• Vert (bon) : de 90 à 100

Nous vous recommandons vivement d’utiliser le calculateur de score Lighthouse (s’ouvre dans un nouvel onglet), qui met immédiatement à jour le score lorsque vous modifiez les paramètres.

N’oubliez pas que pour réussir l’évaluation des Signaux Web essentiels, votre page doit montrer que vous obtenez un score positif pour les trois Signaux Web essentiels:

1. Largest Contentful Paint (LCP)
2. First Input Delay (FID)
3. Cumulative Layout Shift (CLS)

Ressources utiles

• Lighthouse performance scoring explained(opens in a new tab)

Quel avenir pour le Core Web Vitals ?

Nous avons parlé de la situation actuelle des Signaux Web essentiels, mais que nous réserve l’avenir ?

Il est probable que de nombreux changements interviendront au cours des prochaines années, car Google continuera à les peaufiner.

Voici ce que nous savons à ce jour :

• L’ensemble des Signaux Web essentiels s’étoffera au fil du temps : si Google souhaite que le nombre des Signaux Web essentiels  soit aussi faible que possible et qu’ils soient aussi faciles à comprendre et à mesurer que possible, il est probable que l’ensemble s’étoffera au fil du temps. First Contentful Paint (FCP) est, parv exemple, un candidat de choix pour être ajouté.
• Augmentation du poids du  Cumulative Layout Shift (CLS) et ajustements : le poids du CLS sera probablement augmenté(ouvre un nouvel onglet), et l’on cherche à améliorer la gestion des pages de longue durée(ouvre un nouvel onglet), car les décalages de mise en page continuent désormais d’être ajoutés au score CLS après l’interaction.
• Prise en charge de la mesure des performances des animations : l’expérience de l’utilisateur va au-delà du chargement initial de la page, c’est pourquoi Google envisage d’ajouter des indicateurs mesurant les performances des animations.
• Le First Input Delay (FID) pourrait devenir plus strict : l’abaissement du délai FID à 50-75 ms pourrait permettre de mesurer l’expérience de l’utilisateur de manière plus précise (s’ouvre dans un nouvel onglet).
• Meilleure prise en charge des applications à page unique (single page apps – SPA) : lors de l’utilisation de SPA, les transitions de l’application ne disposent pas de mesures de performance car elles n’ont pas d’URL unique. Par exemple, le First Input Delay (FID) et le Largest Contentful Paint (LCP) ne sont mesurés que lors du chargement initial, alors que le Cumulative Layout Shift ne cesse d’augmenter à chaque interaction. C’est pourquoi Google cherche des moyens (s’ouvre dans un nouvel onglet) de mieux mesurer les Signaux Web essentiels  dans les SPA.

Nous nous attendons en outre à ce que :

• Les valeurs vitales de base sont une cible mouvante : pour l’instant, le Moto G4 avec une connexion 3G rapide est le premier à déterminer les Signaux Web essentiels de base de votre page, mais au fur et à mesure que de nouveaux téléphones plus avancés seront développés et disponibles, et que des connexions Internet plus rapides deviendront la norme, nous nous attendons à ce que Google les prenne en compte par défaut.
• Les sites web peuvent commencer à envisager de bloquer le trafic en provenance de marchés non ciblés : les sites web qui reçoivent beaucoup de trafic en provenance de marchés non ciblés qui n’ont pas accès à du matériel et à des connexions internet rapides pourraient envisager d’empêcher les utilisateurs de ces marchés d’accéder au site web, évitant ainsi un éventuel effet négatif sur leurs scores de Core Web Vital.

Avis de non-responsabilité : nous déconseillons cette solution, car elle entraîne une mauvaise expérience pour l’utilisateur.

Questions fréquemment posées sur Core Web Vitals

1. Quel est l’impact de Core Web Vitals sur le référencement ?

Google a déclaré que Core Web Vitals n’aurait probablement qu’un faible impact, mais nous pensons qu’il deviendra un facteur de classement plus important à l’avenir.

La raison ? Tout le monde aime les sites qui offrent une bonne expérience utilisateur. Et les indicateurs Core Web Vitals visent à mesurer cette expérience utilisateur.

En outre, les internautes sont probablement moins enclins à cliquer de nouveau sur le SERP si vous leur offrez une bonne expérience.

Ce comportement est pris en compte par l’algorithme de Google et aura une incidence positive sur les performances de votre page en matière de référencement.

2. Comment réussir l’évaluation Core Web Vitals ?

Vous réussirez l’évaluation Core Web Vitals si vous obtenez un score vert (“bon”) pour les trois Core Web Vitals : Largest Contentful Paint, First Input Delay et Cumulative Layout Shift, sur la base de données d’utilisateurs réels, appelées “données de terrain”.

3. Pourquoi les résultats des données de laboratoire et des données de terrain sont-ils si différents ?

Les données de laboratoire sont collectées dans un environnement simulé qui vise à exécuter de manière fiable les mêmes tests, en utilisant les mêmes paramètres, tandis que les données de terrain sont collectées à partir du comportement d’utilisateurs réels utilisant des appareils différents, avec des connexions internet différentes, à partir de lieux différents.

4. Pourquoi n’y a-t-il pas de données de champ pour mon URL ou mon résumé d’origine ?

Pour les URL individuelles, vous pouvez voir l’avis “Données de terrain – Le rapport d’expérience utilisateur Chrome ne dispose pas de suffisamment de données de vitesse réelles pour cette page”, et pour le résumé de l’origine, “Le rapport d’expérience utilisateur Chrome ne dispose pas de suffisamment de données de vitesse réelles pour cette origine”.

Cela signifie qu’il n’y a pas assez de données CrUX disponibles pour générer une vue anonyme représentative de vos performances.

En d’autres termes, pour que les données CrUX soient disponibles, il faut que votre site soit visité par un plus grand nombre de personnes !

Il est probable que vous accédiez d’abord au résumé de l’origine, car il s’agit d’un agrégat de toutes vos pages.

Ressources utiles

• FAQ sur PageSpeed Insights(ouvre un nouvel onglet)

5. Les pages non indexables ont-elles un impact sur mon Core Web Vitals ?

Il est possible que les pages qui ne sont pas accessibles et/ou indexables pour les moteurs de recherche influencent vos scores Core Web Vitals.

Interrogé en février 2021, John Mueller, de Google, a déclaré qu’elles pouvaient avoir un impact.