Les Core Web Vitals sont trois indicateurs définis par Google pour mesurer l’expérience réelle des visiteurs : la vitesse d’affichage du contenu principal (LCP), la réactivité aux interactions (INP) et la stabilité visuelle de la page (CLS). Ils font partie des signaux d’expérience de page pris en compte par Google, mais surtout, ils traduisent ce que ressentent vos visiteurs. Les comprendre, c’est savoir où concentrer ses efforts pour améliorer la vitesse de son site.
Les trois Core Web Vitals en bref
- LCP (Largest Contentful Paint) : le temps nécessaire pour afficher le plus grand élément visible au chargement, souvent l’image principale ou le titre. Objectif : 2,5 secondes ou moins.
- INP (Interaction to Next Paint) : le délai entre une interaction (clic, appui, saisie) et la mise à jour visible de la page. Il a remplacé l’ancien indicateur FID. Objectif : 200 millisecondes ou moins.
- CLS (Cumulative Layout Shift) : l’ampleur des décalages inattendus de la mise en page, comme le bouton qui se déplace au moment où l’on clique. Objectif : 0,1 ou moins.
Pour être jugée « bonne », une page doit atteindre ces seuils pour au moins 75 % des visites, sur mobile comme sur ordinateur.
Mesurer : données de terrain et données de laboratoire
Il existe deux types de mesures, et les confondre est l’erreur la plus fréquente. Les données de terrain proviennent de vrais visiteurs utilisant Chrome : ce sont elles que Google prend en compte. Vous les trouvez en haut du rapport PageSpeed Insights et dans le rapport « Signaux Web essentiels » de la Search Console. Les données de laboratoire (Lighthouse, en bas du rapport PageSpeed Insights) simulent un chargement : elles sont utiles pour diagnostiquer, mais le score sur 100 n’est pas un Core Web Vital. Un site peut afficher un score moyen dans Lighthouse et passer les trois seuils sur le terrain, ou l’inverse. Un site à faible trafic n’a parfois pas assez de données de terrain : on s’appuie alors sur le laboratoire et sur ses propres mesures.
Améliorer le LCP
- Réduire le temps de réponse du serveur : hébergement adapté, cache de pages, version de PHP récente.
- Ne pas différer le chargement (lazy loading) de l’image principale et lui donner la priorité avec l’attribut
fetchpriority="high". - Compresser les images, les servir en WebP ou en AVIF et aux dimensions réellement affichées.
- Limiter les feuilles de style et les polices qui bloquent l’affichage.
Améliorer l’INP
Un mauvais INP vient presque toujours du JavaScript : quand le navigateur est occupé à exécuter du code, il ne peut pas répondre au clic.
- Faire l’inventaire des scripts tiers (chat, pixels publicitaires, outils d’analyse, carrousels) et supprimer ceux qui ne servent plus.
- Différer le chargement des scripts non essentiels.
- Découper les traitements longs (les tâches de plus de 50 ms bloquent le navigateur) et se méfier des constructeurs de pages qui chargent beaucoup de code sur chaque page.
Améliorer le CLS
- Indiquer les attributs
widthetheightdes images et des vidéos pour réserver leur place. - Réserver l’espace des bannières, des publicités, des contenus intégrés et du bandeau de cookies.
- Maîtriser le chargement des polices (
font-display, préchargement) pour éviter les sauts de texte. - Ne jamais insérer de contenu au-dessus de celui déjà affiché, sauf en réponse à une action du visiteur.
Par où commencer ?
Partez des données de terrain de la Search Console pour repérer les groupes de pages en difficulté, puis analysez une page représentative de chaque groupe. Corrigez un indicateur à la fois et soyez patient : les données de terrain sont calculées sur une période glissante de 28 jours, les améliorations n’apparaissent donc pas immédiatement dans les rapports.
Votre site tourne sous WordPress ? L’optimisation de vitesse WordPress (490 € HT, 50 000 DA en Algérie) traite le cache, les images, les scripts, la base de données et les Core Web Vitals, avec des mesures avant et après. Pour une autre technologie ou un diagnostic plus large, voyez l’audit performance et sécurité.