Core Web Vitals : ce qu’un propriétaire de PME doit vérifier avant juin 2021

Google vient de confirmer que son Page Experience update, qui intègre les Core Web Vitals comme signal de classement pour les résultats de recherche mobile, commencera à se déployer à la mi-juin plutôt qu'en mai comme prévu à l'origine. Ça vous donne quelques semaines de plus, mais pas une raison d'attendre : la meilleure façon de savoir où vous en êtes, c'est de vérifier vous-même dès maintenant plutôt que de découvrir un problème une fois le déploiement commencé. Voici ce que je regarde en premier quand un propriétaire de PME me demande où en est son site, et les correctifs que je priorise sur WordPress.

Qu'est-ce que les Core Web Vitals, exactement?

Les Core Web Vitals sont trois mesures que Google utilise pour évaluer l'expérience réelle d'un visiteur sur une page : la vitesse de chargement, la réactivité aux clics et la stabilité visuelle pendant que la page se charge. Chacune a un seuil précis.

• LCP (Largest Contentful Paint) mesure le temps que prend le plus gros élément visible (souvent une image ou un titre) à s'afficher à l'écran. Google vise 2,5 secondes ou moins.
• FID (First Input Delay) mesure le délai entre le moment où un visiteur clique ou touche quelque chose sur la page et le moment où le navigateur répond réellement à ce clic. Google vise 100 millisecondes ou moins.
• CLS (Cumulative Layout Shift) mesure à quel point les éléments de la page bougent pendant le chargement, par exemple quand un bouton se déplace juste avant que vous cliquiez dessus parce qu'une image vient de finir de charger au-dessus. Google vise un score de 0,1 ou moins.

Les trois se mesurent séparément pour le mobile et pour l'ordinateur, parce que les résultats sont rarement identiques sur les deux.

Le Page Experience update va-t-il vraiment changer votre classement en juin?

Probablement très peu, et c'est important de le dire clairement avant de paniquer sur un score. Google a été explicite : la qualité et la pertinence du contenu restent plus importantes que l'expérience de page, et une page qui répond mieux à une recherche peut encore se classer devant une page plus rapide mais moins pertinente. Le nouveau signal sert surtout de facteur d'égalité entre deux pages qui se valent autrement sur le contenu. Le déploiement lui-même s'étale sur plusieurs semaines à partir de la mi-juin, pas en un seul coup, donc personne ne devrait s'attendre à un changement brutal de trafic le jour même.

Ce que je dis à mes clients, c'est que les Core Web Vitals valent la peine d'être corrigés même si le classement ne bougeait pas d'un poil, parce qu'un site plus rapide et plus stable convertit mieux. C'est la vraie raison de s'en occuper, le signal de classement n'est qu'un bonus.

Comment vérifier vos propres Core Web Vitals dès maintenant?

Deux outils gratuits suffisent pour avoir un premier portrait.

PageSpeed Insights, l'outil gratuit de Google, analyse une seule URL à la fois et donne deux types de données : les données de terrain, tirées de visiteurs réels sur Chrome durant les 28 derniers jours si le site reçoit assez de trafic pour en avoir, et les données de laboratoire, générées sur le moment par un test simulé. Les données de terrain sont ce que Google utilise réellement pour le classement; les données de laboratoire servent surtout à diagnostiquer pourquoi.

Le rapport Core Web Vitals de Search Console donne un portrait de l'ensemble du site plutôt que d'une seule page. Il regroupe vos URL par statut (Médiocre, À améliorer, Bon) séparément pour mobile et ordinateur, ce qui aide à voir si le problème touche tout le site ou seulement un type de page en particulier, comme les fiches produits ou les articles de blogue.

Je commence toujours par Search Console pour voir l'ampleur du problème, puis j'utilise PageSpeed Insights sur les pages les plus consultées pour comprendre la cause exacte.

Comment je lis un rapport PageSpeed Insights avec un client, en mots simples?

La première chose que je fais, c'est d'ignorer le gros chiffre en haut du rapport, le score sur 100. Ce score mélange plusieurs mesures techniques dans une seule note qui ne dit pas grand-chose à un propriétaire de PME et qui peut même induire en erreur, parce qu'un site peut avoir un mauvais score tout en réussissant très bien ses trois Core Web Vitals. Je descends directement aux trois mesures et je les traduis une par une.

Pour le LCP, je regarde quel élément Google a identifié comme le plus gros de la page, presque toujours une photo d'en-tête ou un titre principal, et j'explique que c'est cette image-là précisément qui ralentit tout, pas le site en général. Pour le CLS, je fais défiler la page avec le client pendant le chargement et je lui montre en direct le bouton ou le menu qui saute de place, ce qui rend le problème concret plutôt qu'abstrait. Pour le FID, comme cette mesure vient des visiteurs réels et ne se voit pas dans un test simulé, j'explique plutôt ce qui cause généralement un délai, souvent un script publicitaire ou un widget de clavardage qui accapare le navigateur au chargement.

L'objectif de cette étape n'est pas de rendre le client expert en performance web, c'est de lui montrer que chaque chiffre correspond à quelque chose de réel et corrigeable sur son propre site.

Quels correctifs WordPress on priorise en premier?

Sur la grande majorité des sites WordPress de PME que j'ai vérifiés cette année, les mêmes causes reviennent, et je les corrige dans cet ordre.

1. Les images non compressées et mal dimensionnées. C'est la cause la plus fréquente d'un mauvais LCP. Une photo de 4 000 pixels de large chargée dans un espace de 800 pixels force le navigateur à télécharger un fichier inutilement lourd. Je compresse et je redimensionne l'image à la taille réellement affichée avant de la remettre en ligne.
2. L'hébergement et la mise en cache. Un hébergement partagé bon marché qui sert des centaines de sites sur le même serveur donne souvent un temps de réponse initial lent, peu importe à quel point le reste du site est optimisé. J'ajoute une extension de mise en cache et, quand le budget le permet, je recommande un changement d'hébergeur.
3. Les scripts qui bloquent l'affichage. Chaque widget de clavardage, chaque carrousel d'images et chaque extension de réseaux sociaux ajoute un script que le navigateur doit charger avant d'afficher le reste. Je retire ou je retarde le chargement de ce qui n'est pas essentiel à la première seconde d'affichage.
4. Les images sans dimensions réservées. C'est la cause la plus fréquente d'un mauvais CLS : sans largeur et hauteur précisées dans le code, le navigateur ne sait pas quel espace laisser pour l'image avant qu'elle finisse de charger, alors tout le contenu en dessous saute d'une place à l'autre. J'ajoute les dimensions manquantes, ce qui règle le problème presque instantanément.

Ces quatre corrections couvrent la majorité des cas que je vois, et elles ne demandent généralement pas de refaire le site au complet.

Qu'est-ce qui peut attendre après juin?

Tout ne doit pas être parfait avant le déploiement. Une fois les quatre correctifs ci-dessus en place, le reste (optimisation plus fine des polices web, chargement différé des images sous la ligne de flottaison, révision complète de l'hébergement) peut se faire graduellement, parce que le déploiement lui-même s'étale sur des semaines et que le contenu pertinent continue de peser plus lourd que la vitesse dans le classement. Ce qui compte le plus avant juin, c'est de savoir où vous en êtes et d'avoir réglé les causes les plus lourdes, pas d'avoir un score parfait.

C'est le genre de vérification que je fais systématiquement avant de commencer une refonte de site web : mesurer les Core Web Vitals actuels, corriger ce qui pèse le plus lourd, puis reconstruire sur cette base plutôt que d'empiler un nouveau design sur les mêmes problèmes.

Rédigé avec l'aide d'outils d'IA, vérifié et publié par Marven Salgado.