L’expérience de page et les indicateurs Core Web Vital entrera officiellement en compte dans le ranking en mai 2021

Source: Google
Le moyen le plus simple de voir ces mesures pour votre site est le rapport Signaux Web essentiels dans la Google Search Console. Vous pourrez rapidement y voir si vos pages sont dans la catégorie “URL lentes”, “URL à améliorer” ou “URL rapide”.

En explorant ce rapport, vous pourrez trouver des informations plus détaillées sur les différents problèmes et une liste des pages affectées.

Fait 1 : Les mesures sont divisées en desktop et mobile, mais seuls les signaux mobiles seront utilisés pour le positionnement des pages. Google va passer en indexation 100% mobile-first, cela fait donc sens d’utiliser les signaux de vitesse mobile puisque l’indexation va se baser sur ces versions des pages.
Fait 2 : Les données proviennent du Chrome User Experience Report (CrUX) qui enregistre les données des utilisateurs de Chrome qui l’autorisent. Les seuils de note sont fixés sur 75% des utilisateurs. Donc si 70% des utilisateurs sont dans la catégorie “bonne” et que 5% dans la catégorie “à améliorer”, la page sera jugée comme “à améliorer”.
Fait 3 : Les mesures vont être prises pour chaque page, mais John Mueller déclare que s’il n’y a pas suffisamment de données, ce sont les mesures de certaines parties ou de tout le site qui pourraient être utilisées.
Fait 4 : Avec l’ajout de ces nouvelles mesures, l’AMP ne sera plus requise pour être dans les Top Stories sur mobile. Comme les nouvelles stories n’auront pas réellement de données sur la vitesse, il y a des chances que ce soient celles d’un groupement de pages ou de tout le domaine qui soient prises en compte.
Fait 5 : Les applications web monopages (Single Page Applications ou SPA) ne mesurent pas le FID et le LCP via les transitions de page. Nous en reparlerons un peu plus bas.
Fait 6 : Les mesures peuvent changer au fil du temps, et les seuils de 75% aussi. Google a déjà changé ses méthodes pour mesurer la vitesse d’une page dans leurs outils ainsi que les seuils pour lesquels une page est considérée comme rapide ou non. Il y a de grandes chances que cela change encore dans le futur. D’ailleurs, nous avons travaillé l’an dernier à améliorer ces mesures pour notre site l’an dernier, mais nous avons déjà besoin de le refaire pour répondre aux modifications de Google.
Pour remettre les choses à plat, souvenez-vous qu’il existe plus de 200 facteurs de ranking. Il ne faut pas s’attendre à voir un bond dans son référencement en améliorant les Core Web Vitals. Personne ne sait réellement à quel point cela va influencer les positionnements, mais il y a peu de chance que le signal soit si fort que cela. Surtout si l’on considère que beaucoup d’aspects de l’expérience utilisateur sont déjà utilisés par Google pour le ranking.
Voyons chacun de ces Core Web Vitals en détail.
Voici les trois composants actuels des Core Web Vitals:
Largest Contentful Paint (LCP) — loading
Le LCP est l’élément visible le plus grand chargé sur l’écran (le viewport).

Source : web.dev/vitals
L’élément le plus grand est généralement une image mise en avant pour le <h1> mais peut aussi être l’un de ces éléments :
- Élément <img>
- Élément <image> dans un élément <svg>
- L’image dans un élément <video>
- L’image de fond charger avec la fonction url()
- Bloc de texte
Les <svg> et <video> pourraient être ajoutés dans le futur.
Comment voir le LCP
Dans PageSpeed Insights, l’élément LCP sera donné dans la section Diagnostic. Pour la page que nous testons ici, le LCP est l’image mise en avant de l’article.

Dans les DevTools de Chrome, suivez ces étapes :
- Performance > cochez “Screenshots”
- Cliquez sur “start profiling and reload page”
- Le LCP est sur la frise chronologique
- Cliquez sur le node, c’est l’élément pour le LCP

Optimiser le LCP
Notre élément LCP sur cette page et beaucoup d’autres est l’image mise en avant. Pour améliorer cela, nous pourrions précharger l’image on la mettre en inline pour la charger en même temps que le code HTML. Il faut simplement que l’image charge plus vite qu’actuellement.
Resources
- Optimize Largest Contentful Paint — web.dev
- Investigating Largest Contentful Paint — Paul Irish (video)
- How to Improve Page Speed from Start to Finish — Ahrefs
Cumulative Layout Shift (CLS) — Stabilité visuelle
Le CLS mesure la manière dont les éléments d’une page vont bouger et la stabilité de la structure. Cela prend en compte la taille de l’élément et comment il va bouger. L’un des problèmes de cette mesure est qu’elle continue à être calculée même après le chargement initial. Google est en train de prendre en compte les retours sur cette donnée, nous verrons donc certainement des changements à ce sujet dans le futur.

Source : web.dev/vitals
Lorsque vous voulez cliquer sur quelque chose, que la page bouge et que vous finissez par cliquer sur un autre élément, cela peut être très énervant. Ça m’arrive en permanence. Je clique sur quelque chose et, soudainement, j’ouvre une pub voire je change de site. C’est quelque chose de très frustrant en tant qu’utilisateur.

Les principaux problèmes dans le CLS sont :
- Les images sans dimension
- Les pubs, les éléments embarqués ou les iframes sans dimension
- L’injection de contenu en JavaScript
- Appliquer des polices ou des styles tardivement dans le chargement
Comment voir le CLS
Dans PageSpeed Insights, dans Diagnostics, vous trouverez une liste des éléments qui bougent.

En utilisant WebPageTest. Dans la vue Filmstrip, utilisez les options suivantes :
- Highlight Layout Shifts
- Thumbnail Size: Huge
- Thumbnail Interval: 0.1 sec
Sur notre exemple : les polices changent de style entre 5.1 et 5.2 secondes, ce qui fait bouger la structure lorsque la police est appliquée.

Vous pouvez également essayer Layout Shift GIF Generator.

Smashing Magazine a aussi utilisé une technique intéressante : ils ont tout entouré d’un contour rouge de 3px et ont enregistré une vidéo de leur page en train de charger pour déterminer où il y a des changements de structure.
Optimiser le CLS
Pour notre page test, ce que nous pourrions essayer de faire est de précharger notre police ou l’abandonner complètement (peu de chance que nous choisissons cette option) ou encore utiliser une police par défaut dans le chargement initial et ne charger notre police que sur les chargements des pages suivantes. Cela peut poser des problèmes de style, d’image de marque, de cohérence, etc. Nous allons devoir prendre une décision pour le futur.
Resources
- What forces layout/reflow — Paul Irish
- Optimize Cumulative Layout Shift — web.dev
- Debugging Layout Shifts — web.dev
- Understanding Cumulative Layout Shift — Annie Sullivan (video)
- How to avoid layout shifts caused by web fonts — Simon Hearne
First Input Delay (FID) — interactivité
Le FID est le temps qu’il va falloir à votre page pour répondre à une interaction avec un utilisateur. Voyez ça comme son temps de réaction. Cela ne prend pas en compte le scroll ou le zoom.
Exemples d’interactions :
- Cliquer sur un lien ou un bouton
- Entrer du texte dans un champ de formulaire
- Sélectionner un menu déroulant
- Cliquer sur une case à cocher.
Essayer de cliquer sur quelque chose sur une page et que ça n’ait pas d’effet peut être très frustrant.

Source : web.dev/vitals
Tous les utilisateurs ne vont pas interagir avec une page, donc il n’y aura pas toujours une valeur de FID. C’est aussi la raison pour laquelle les outils de test ne proposeront pas cette mesure, car ils n’interagissent pas avec la page. Il faut se référer au TBT (Total Blocking Time) à la place.
Les causes du FID
Il s’agit des éléments Javascript en compétition dans le thread principal. Il n’y a qu’un seul thread (ou tâche) principal et JavaScript essaye de faire passer des tâches dessus.
Pendant qu’un thread est train de charger, une page ne peut pas répondre aux inputs d’un utilisateur. C’est à ce moment-là que l’on ressent du délai. Plus longue est la tâche, plus grand sera le délai. Les pauses entre les tâches sont les seules opportunités où une page va pouvoir prendre en compte la demande de l’utilisateur.
Optimiser le FID
Je n’ai repéré aucun problème de FID sur notre site mais, en règle générale, il faut diviser les tâches longues et retarder tout JavaScript non indispensable pour plus tard.
Resources
La différence entre les données de “laboratoire” et les données réelles est que les données réelles se fient aux véritables utilisateurs, aux vitesses et stabilités de connexion, aux appareils utilisés, au cache, etc. Les données de laboratoire sont toujours testées dans les mêmes conditions en espérant que les résultats soient cohérents et répétables.
Données réelles
LCP | FID | CLS | |
---|---|---|---|
Chrome User Experience Report | ✔ | ✔ | ✔ |
PageSpeed Insights | ✔ | ✔ | ✔ |
Google Search Console (Core Web Vitals report) | ✔ | ✔ | ✔ |
Web-vitals JavaScript library | ✔ | ✔ | ✔ |
web.dev | ✔ | ✔ | ✔ |
Web Vitals Extension | ✔ | ✔ | ✔ |
Données de laboratoire
LCP | FID | CLS | |
---|---|---|---|
Chrome DevTools | ✔ | ✘ (utilise TBT) | ✔ |
Lighthouse | ✔ | ✘ (utilise TBT) | ✔ |
WebPageTest | ✔ | ✘ (utilise TBT) | ✔ |
PageSpeed Insights | ✔ | ✘ (utilise TBT) | ✔ |
web.dev | ✔ | ✘ (utilise TBT) | ✔ |
J’aime beaucoup les résultats de GSC, car on peut voir les données de plusieurs pages à la fois. Mais elles sont en décalage avec une moyenne de 28 jours, donc les changements peuvent mettre beaucoup de temps à être visibles dans le rapport. Dans Chrome 88, Google ajoute directement les Core Web Vitals dans le DevTools.
Vous pouvez aussi examiner comment Lighthouse calcule les valeurs et suivre l’impact de vos changements.

Conclusion
Améliorer les Core Web Vitals, c’est améliorer l’expérience utilisateur, c’est donc quelque chose d’important. Il est trop tôt pour savoir quel impact cela va avoir sur le SEO, mais comme j’en parle dans mon article sur la vitesse d’une page, cela va vous aider à enregistrer plus de données dans vos analytics ce qui va donner “l’impression” d’une amélioration.
Rapprochez-vous de vos développeurs : ce sont eux les experts sur ce sujet. La vitesse d’une page peut être un sujet extrêmement complexe. Si vous êtes seul à vous charger d’un site, vous aurez peut-être besoin de vous appuyer sur des plugins ou services tiers pour vous aider, comme WP Rocket ou NitroPack.