Les Core Web Vitals expliqués aux propriétaires de sites web

Les Core Web Vitals sont trois mesures que Google utilise pour décrire l'impression que donne une page à un véritable visiteur : la rapidité avec laquelle le contenu principal apparaît, la rapidité avec laquelle la page réagit lorsque quelqu'un touche ou clique, et le fait que la mise en page saute ou non pendant le chargement. Elles font partie des signaux d'expérience de page de Google, mais la raison la plus importante de s'en soucier est plus simple. Les visiteurs quittent les pages lentes et instables, et ils vous disent rarement pourquoi.

Ce guide explique les trois indicateurs en langage clair, les seuils publiés par Google, et comment décider quoi corriger en premier sur un site normal de petite entreprise.

Les trois indicateurs en un coup d'œil

Indicateur	Ce qu'il mesure	Bon	Mauvais
LCP (Largest Contentful Paint)	Délai avant l'affichage de l'élément visible le plus grand	2,5 secondes ou moins	Plus de 4 secondes
INP (Interaction to Next Paint)	Temps que met la page à réagir visuellement après un toucher, un clic ou une frappe	200 millisecondes ou moins	Plus de 500 millisecondes
CLS (Cumulative Layout Shift)	Ampleur des déplacements inattendus du contenu visible	0,1 ou moins	Plus de 0,25

Les valeurs situées entre « bon » et « mauvais » tombent dans une zone « à améliorer ». Google évalue une page au 75e centile des visites réelles, ce qui signifie que trois quarts de vos visiteurs doivent bénéficier d'une expérience au moins égale au seuil. Un seul test rapide sur votre propre ordinateur portable ne prouve pas que la page réussit.

Largest Contentful Paint : la page s'affiche-t-elle ?

Le LCP examine la plus grande image, le plus grand poster vidéo ou le plus grand bloc de texte du premier écran et enregistre le moment où son rendu est terminé. Sur la plupart des sites, il s'agit d'une grande image d'en-tête ou d'un gros titre. Un LCP lent vient généralement de l'une de ces quatre causes : une réponse lente du serveur, une image lourde ou mal formatée, du CSS ou du JavaScript bloquant le rendu, ou le navigateur qui découvre trop tard l'image clé.

Interaction to Next Paint : la page répond-elle ?

L'INP a remplacé l'ancien indicateur First Input Delay en mars 2024. Là où le First Input Delay ne regardait que la première interaction et seulement le délai avant son démarrage, l'INP prend en compte les interactions tout au long de la visite et en retient l'une des plus lentes, de l'action jusqu'à l'affichage de l'image suivante. Les pages qui se chargent vite mais donnent une impression de lourdeur quand on ouvre un menu ou qu'on appuie sur un bouton ont généralement un problème de JavaScript : trop de code exécuté en même temps sur le fil principal.

Cumulative Layout Shift : la page reste-t-elle stable ?

Le CLS additionne les mouvements inattendus des éléments visibles. Vous l'avez ressenti lorsque vous alliez toucher un lien et qu'une bannière s'est chargée au-dessus, repoussant le lien vers le bas. Les déclencheurs courants sont les images sans attributs de largeur et de hauteur, les publicités et intégrations qui se chargent tard, les polices qui s'échangent et changent la taille du texte, et les bandeaux de cookies injectés en haut de la page.

Données de laboratoire et données de terrain

Il existe deux types de mesure, et les confondre crée de la confusion.

• Les données de terrain proviennent de visiteurs réels utilisant de vrais appareils et réseaux. Google les collecte auprès des utilisateurs de Chrome et les affiche dans PageSpeed Insights et Search Console lorsque votre site a assez de trafic. Ce sont elles qui comptent pour l'évaluation.
• Les données de laboratoire proviennent d'un test simulé, comme Lighthouse. Elles sont reproductibles, ce qui les rend idéales pour le débogage, mais elles concernent un seul appareil sur une seule connexion.

Un petit site peut n'avoir aucune donnée de terrain. Dans ce cas, utilisez les tests de laboratoire pour trouver les problèmes et considérez les résultats comme des repères, pas comme un verdict.

Par où commencer les corrections

1. Mesurez les pages qui comptent. Testez votre page d'accueil, votre page d'atterrissage la plus visitée et un article ou une page produit typique avec un profil mobile. Ne faites pas la moyenne de tout le site.
2. Corrigez d'abord l'indicateur le plus faible. Si le LCP est mauvais et le CLS correct, travaillez sur le LCP.
3. Commencez par les gains faciles. Compressez et redimensionnez l'image d'en-tête, définissez les dimensions des images, activez la mise en cache, envisagez un CDN, et supprimez les extensions ou scripts que vous n'utilisez plus.
4. Retestez après chaque changement. Ne modifiez qu'un élément à la fois pour savoir ce qui a aidé.
5. Attendez que les données de terrain rattrapent. Les chiffres en conditions réelles sont collectés sur une période glissante : les améliorations mettent quelques semaines à apparaître complètement.

Le rapport avec l'hébergement

Les Core Web Vitals dépendent surtout de la manière dont une page est construite, mais l'hébergement fixe le plancher. Une réponse lente du serveur retarde tout ce qui suit, ce qui nuit directement au LCP. Des serveurs surchargés, des versions de PHP obsolètes et l'absence de cache côté serveur ajoutent tous du temps avant que le navigateur ne reçoive le premier octet. Un bon travail côté front-end ne peut pas compenser entièrement un back-end lent.

Une attente réaliste

Réussir les trois indicateurs est un objectif qui en vaut la peine, mais ce n'est pas un interrupteur magique de classement. La pertinence du contenu compte encore bien davantage. Voyez les Core Web Vitals comme une suppression de frictions : ils ne feront pas bien classer une page faible, mais une page lente et instable rend plus difficile la rétention des visiteurs que vous avez déjà gagnés.

Erreurs courantes des propriétaires de sites

• Courir après un score Lighthouse parfait. Un score de 100 dans un test de laboratoire n'est pas l'objectif. L'objectif, c'est de franchir les trois seuils pour les visiteurs réels.
• Tester uniquement sur ordinateur. L'essentiel de l'évaluation se fait sur mobile, et les appareils mobiles ont des processeurs et des connexions plus lents.
• Installer une extension de vitesse et s'arrêter là. Les extensions peuvent aider pour la mise en cache et le traitement des images, mais elles ne peuvent pas supprimer une image d'en-tête de 3 Mo ni une douzaine de scripts marketing.
• Ignorer les modèles. Les pages construites à partir du même modèle partagent généralement les mêmes problèmes : corriger le modèle corrige de nombreuses pages d'un coup. Search Console regroupe les URL similaires précisément pour cette raison.

Tenez un simple journal de ce que vous avez modifié, avec le score avant et après. Cela évite de tâtonner quand quelque chose régresse après une mise à jour d'extension.

Les pages rapides commencent par le serveur

Sur Zebra Hosting Cloud, chaque offre inclut le panneau de contrôle Plesk, où vous pouvez choisir des versions actuelles de PHP, et le CDN Cloudflare est disponible sur les sites hébergés pour servir les fichiers statiques au plus près des visiteurs. Ensemble, ils couvrent le côté serveur de l'équation pour que vous puissiez vous concentrer sur la page elle-même. Découvrez ce qu'offre chaque formule sur la présentation de l'hébergement.