Core Web Vitals : les trois métriques Google qui mesurent l'expérience de votre site web
En mai 2021, Google a officialisé que la vitesse et l’expérience de chargement d’un site web allaient influencer son positionnement dans les résultats de recherche. Depuis, les Core Web Vitals sont devenus un sujet incontournable dans le monde du référencement naturel. Mais pour beaucoup de propriétaires de PME, ces trois métriques restent abstraites — LCP, INP, CLS — des acronymes qui apparaissent dans PageSpeed Insights sans qu’on sache vraiment ce qu’ils mesurent ni pourquoi ils comptent. En tant qu’agence web à Montréal qui accompagne des PME depuis plus de 25 ans, on vous explique ici ce que sont les Core Web Vitals, comment les mesurer sur votre site WordPress, et ce que vous pouvez faire pour les améliorer.
Qu’est-ce que les Core Web Vitals ?
Les Core Web Vitals (CWV) sont un ensemble de métriques définies par Google pour mesurer la qualité de l’expérience utilisateur sur une page web. Contrairement aux métriques techniques classiques — comme le temps de chargement brut ou le poids total de la page — les Core Web Vitals se concentrent sur ce que l’utilisateur perçoit réellement : est-ce que le contenu principal s’affiche rapidement ? Est-ce que la page réagit quand je clique ? Est-ce que la mise en page bouge de façon inattendue pendant le chargement ?
Il y en a trois. Le LCP (Largest Contentful Paint) mesure la vitesse d’affichage du contenu principal. L’INP (Interaction to Next Paint) mesure la réactivité aux interactions. Le CLS (Cumulative Layout Shift) mesure la stabilité visuelle. Chacun a des seuils précis qui définissent ce qui est considéré « bon », « à améliorer » ou « faible ».
Ces trois métriques sont mesurables, chiffrées, et directement liées au comportement réel des visiteurs. C’est ce qui les distingue des métriques purement techniques : elles reflètent l’expérience vécue, pas seulement les performances techniques sous-jacentes.
Pourquoi Google les a intégrés comme signal de classement
Google a un intérêt évident à envoyer ses utilisateurs vers des pages qui offrent une bonne expérience. Un résultat de recherche qui mène vers une page lente à charger, instable, ou peu réactive nuit à la satisfaction de l’utilisateur — et donc, indirectement, à la réputation de Google comme moteur de recherche.
Depuis mai 2021, les Core Web Vitals font officiellement partie des Page Experience Signals — les signaux d’expérience de page que Google utilise comme facteur de classement dans ses résultats. Ce n’est pas le facteur dominant (la pertinence du contenu reste primordiale), mais à contenu équivalent entre deux pages concurrentes, celle avec de meilleurs Core Web Vitals aura un avantage.
En mars 2024, Google a remplacé le FID (First Input Delay) par l’INP (Interaction to Next Paint) comme troisième métrique officielle des Core Web Vitals. L’INP mesure la réactivité de façon plus complète et plus représentative de l’expérience réelle de l’utilisateur.
Les trois métriques des Core Web Vitals expliquées
LCP — Largest Contentful Paint
Le LCP mesure le temps nécessaire pour que le plus grand élément de contenu visible dans la fenêtre initiale de l’utilisateur soit affiché à l’écran. Dans la pratique, cet élément est presque toujours l’image principale de la page (le héros), le titre en très grand format, ou un grand bloc de texte en haut de page.
Seuils officiels Google : un LCP inférieur à 2,5 secondes est bon. Entre 2,5 et 4 secondes, il y a place à amélioration. Au-delà de 4 secondes, la performance est faible.
Sur WordPress, le LCP est souvent affecté par des images non compressées placées en en-tête de page. Une image JPEG de 2 Mo peut à elle seule faire passer le LCP de 1,5 à 6 secondes. La conversion en WebP, la définition d’un attribut loading="eager" sur l’image principale (pour lui dire de se charger en priorité), et l’utilisation d’un hébergement performant avec cache sont les interventions les plus efficaces pour améliorer le LCP.
INP — Interaction to Next Paint
L’INP est entré en vigueur en mars 2024 en remplacement du FID. Il mesure la réactivité globale d’une page à toutes les interactions de l’utilisateur pendant sa visite : clics sur des liens ou boutons, frappes au clavier dans un formulaire, appuis sur écran tactile. Le FID ne mesurait que la première interaction — l’INP mesure toutes les interactions et retient la plus lente (en excluant les valeurs aberrantes).
Seuils officiels Google : un INP inférieur à 200 millisecondes est bon. Entre 200 et 500 ms, des améliorations sont nécessaires. Au-delà de 500 ms, la page est considérée peu réactive.
Un INP élevé est généralement causé par du JavaScript lourd qui bloque le fil d’exécution principal du navigateur pendant trop longtemps. Sur WordPress, les causes fréquentes sont des plugins trop nombreux, des page builders lourds qui chargent beaucoup de code JavaScript, et des scripts tiers (chat en direct, suivi marketing, widgets réseaux sociaux) non optimisés.
CLS — Cumulative Layout Shift
Le CLS mesure la quantité de mouvement inattendu dans la mise en page d’une page pendant son chargement. Chaque fois qu’un élément se déplace de façon non initiée par l’utilisateur — une image qui se charge et fait descendre le texte, une bannière qui apparaît et repousse le contenu, une police qui se substitue et change la taille du texte — Google enregistre ce déplacement et l’ajoute au score CLS.
Seuils officiels Google : un CLS inférieur à 0,1 est bon. Entre 0,1 et 0,25, il y a place à amélioration. Au-delà de 0,25, l’expérience utilisateur est clairement perturbée.
Le CLS est particulièrement irritant pour les utilisateurs sur mobile : un bouton qui se déplace au moment où vous allez cliquer dessus, ou un texte qui recule pendant que vous le lisez, sont des expériences frustrantes qui nuisent à la crédibilité du site. Sur WordPress, les principales sources de CLS sont les images auxquelles on n’a pas défini de dimensions fixes (width et height), les polices web qui remplacent tardivement les polices système, et les publicités ou pop-ups qui s’insèrent dans la mise en page après le chargement initial.
Comment mesurer vos Core Web Vitals
Plusieurs outils permettent de mesurer les Core Web Vitals de votre site WordPress. Voici les plus accessibles.
Google PageSpeed Insights est le point de départ le plus simple. En entrant l’URL de votre page sur pagespeed.web.dev, vous obtenez les trois métriques CWV (LCP, INP, CLS) ainsi que le FCP, avec un code couleur clair. Si votre site reçoit suffisamment de trafic, les données de terrain (issues de vrais utilisateurs de Chrome) sont aussi affichées.
Google Search Console inclut un rapport dédié aux Core Web Vitals (dans la section « Expérience »). Il groupe vos pages en trois catégories — bonnes, à améliorer, faibles — et indique quelles URLs ont des problèmes. C’est la vue la plus complète et la plus fiable, car elle est basée sur les données réelles de vos visiteurs.
Google Lighthouse, accessible depuis les outils de développement de Chrome (touche F12 → onglet Lighthouse), permet d’auditer n’importe quelle page dans un environnement contrôlé. Utile pour tester des modifications avant de les mettre en ligne.
Ce qui affecte vos Core Web Vitals sur WordPress
Les problèmes de Core Web Vitals sur WordPress ont des causes bien identifiées. Pour le LCP : images lourdes non compressées, hébergement lent avec un TTFB (Time to First Byte) élevé, absence de cache de page, et ressources CSS/JS bloquant le rendu. Pour l’INP : plugins trop nombreux chargeant du JavaScript lourd, page builders qui génèrent des arbres DOM volumineux, et scripts tiers non chargés en différé. Pour le CLS : images sans dimensions définies, polices web chargées sans directive font-display: swap, et éléments injectés dans la page après le chargement initial (publicités, pop-ups, bannières de cookies).
Comment améliorer ses Core Web Vitals sur WordPress
Les interventions suivantes produisent les gains les plus significatifs, par ordre d’impact.
Hébergement performant avec LiteSpeed Server et Redis. Le TTFB est le point de départ du LCP. Un hébergement WordPress géré avec LiteSpeed Server, Redis et CDN activé améliore le LCP de façon structurelle — avant même de toucher au code. Consultez aussi notre guide pour tester la vitesse de votre hébergement.
Cache de page avec LiteSpeed Cache. Un cache de page bien configuré — notamment LiteSpeed Cache sur WordPress — réduit le TTFB et améliore le LCP significativement. Le cache d’objets Redis accélère les requêtes à la base de données, réduisant le temps de génération de chaque page.
Optimisation des images. Convertissez toutes les images en WebP. Définissez les attributs width et height sur chaque image pour éviter le CLS. Ajoutez loading="lazy" sur les images hors de la fenêtre initiale, et loading="eager" sur l’image principale (celle qui contribue au LCP) pour prioriser son chargement.
Polices web avec font-display: swap. Ajoutez la directive font-display: swap à vos déclarations de polices web. Cette directive indique au navigateur d’afficher une police système pendant le chargement de la police web, évitant le flash invisible et le CLS que peut causer une police web tardive.
Réduction et différé du JavaScript. Chargez les scripts non critiques (analyse, chat, réseaux sociaux) avec l’attribut defer ou async. Réduisez le nombre de plugins actifs — chaque plugin supplémentaire peut ajouter du JavaScript au fil d’exécution principal et augmenter l’INP.
Pourquoi les Core Web Vitals sont plus difficiles à atteindre sur mobile
La version mobile de votre site fait presque toujours l’objet d’un rapport CWV distinct — et les métriques mobiles sont systématiquement plus mauvaises que les métriques bureau. La raison est structurelle : Google mesure les Core Web Vitals mobiles avec une connexion simulée 4G et un processeur mobile de puissance moyenne. Ces conditions reproduisent la réalité d’une part significative de vos visiteurs, mais elles sont beaucoup plus exigeantes que celles d’un ordinateur connecté en filaire.
Pour un site WordPress typique, un LCP de 1,8 seconde sur bureau peut atteindre 3,5 secondes sur mobile. La différence s’explique par la connexion (4G vs fibre) et par la puissance de traitement disponible pour exécuter le JavaScript. Un INP excellent sur bureau peut devenir problématique sur mobile si votre page charge beaucoup de scripts que le processeur mobile peine à exécuter rapidement.
La cible prioritaire est le mobile : si vos Core Web Vitals sont dans la zone verte sur mobile, ils le seront presque certainement sur bureau aussi. Optimiser uniquement pour bureau revient à négliger l’expérience de la majorité de vos visiteurs.
Core Web Vitals et Google Search Console : le rapport à surveiller
Dans Google Search Console, le rapport Core Web Vitals (section « Expérience ») est la vue la plus complète pour surveiller l’évolution de vos métriques. Il affiche deux onglets séparés — mobile et bureau — et classe vos pages en trois catégories : bonnes, à améliorer, et faibles. Il indique aussi les erreurs spécifiques qui affectent chaque groupe d’URLs.
Quand Google détecte une amélioration significative de vos Core Web Vitals, il met à jour ce rapport sous 28 jours. C’est le délai de collecte des données terrain. Ne vous attendez pas à voir les effets de vos optimisations immédiatement : un mois de recul est nécessaire pour que les données reflètent les changements apportés à votre site.
Ce qu’on a observé chez un client dans le secteur événementiel à Montréal
En 2025, un organisme événementiel basé à Montréal présentait un score CLS de 0,38 sur mobile — largement dans la zone rouge. L’audit a révélé deux causes principales : des images de programmation sans dimensions définies (qui se redimensionnaient au chargement) et une police Google Fonts chargée sans font-display: swap (ce qui causait un saut visible de mise en page à l’apparition du texte). Après correction de ces deux points et activation du cache LiteSpeed, le CLS est tombé à 0,04 et le score PageSpeed global est passé de 44 à 82 sur mobile. Les plaintes des visiteurs concernant la mise en page « qui saute » ont cessé.
Performance et hébergement : notre approche
Améliorer les Core Web Vitals n’est pas un projet ponctuel — c’est une pratique continue. Les mises à jour de WordPress, l’ajout de nouveaux plugins, ou un changement de contenu peuvent faire évoluer vos métriques. On intègre la surveillance des Core Web Vitals dans nos mandats de maintenance et d’hébergement WordPress pour que nos clients maintiennent des scores élevés dans le temps.
