Un score de 100/100 sur un outil de test et des Core Web Vitals catalogués « à améliorer » dans Google Search Console : ce grand écart est l’une des sources de confusion les plus fréquentes chez les entrepreneurs et responsables marketing qui suivent le SEO de leur site. Les Core Web Vitals ne sont pas un score parmi d’autres, ce sont les métriques que Google utilise pour juger si l’expérience vécue par vos visiteurs réels est bonne, moyenne ou mauvaise. Comprendre ce qu’elles mesurent, comment les lire sans se tromper et dans quel ordre les corriger fait souvent la différence entre un audit qui reste dans un tiroir et des gains concrets de trafic.
Les Core Web Vitals : définition
Les Core Web Vitals sont trois métriques définies par Google pour évaluer l’expérience réellement vécue par un internaute sur une page web : la vitesse à laquelle le contenu principal s’affiche, la rapidité avec laquelle la page répond aux interactions, et la stabilité visuelle du contenu pendant le chargement. Introduites en 2020, elles ont été révisées en mars 2024 : le First Input Delay (FID) a été retiré du trio au profit de l’Interaction to Next Paint (INP), jugée plus représentative de la réactivité d’une page sur l’ensemble de sa durée de vie, et non plus seulement au premier clic.
Concrètement, chaque Core Web Vital répond à une question que l’utilisateur ne formule jamais mais ressent immédiatement : la page s’affiche-t-elle vite, répond-elle quand je clique ou je tape, et le contenu bouge-t-il sous mes yeux pendant que j’essaie de le lire ? Google a retenu ces trois signaux parce qu’ils sont mesurables à l’échelle de millions de sites, corrélés à la satisfaction des utilisateurs, et surtout actionnables par les équipes techniques, contrairement à des notions plus floues comme le ressenti général de qualité d’un site.
Pourquoi mesurer les Core Web Vitals est essentiel pour l’expérience utilisateur et le SEO
Un impact direct sur le comportement des visiteurs
Une page qui tarde à afficher son contenu principal, qui ne répond pas immédiatement à un clic ou dont les boutons se déplacent pendant le chargement génère de la frustration, et cette frustration se traduit en abandon. Sur mobile, où la connexion et la puissance du terminal sont souvent moins favorables qu’en labo, l’effet est amplifié : un formulaire de contact, un bouton d’ajout au panier ou un menu qui réagit avec retard coûte des conversions avant même qu’un visiteur n’ait eu le temps de juger votre offre.
Un signal de classement confirmé, mais pondéré
Les Core Web Vitals font partie du signal « expérience de page » que Google utilise dans son algorithme de classement, aux côtés de la compatibilité mobile, du HTTPS et de l’absence d’interstitiels intrusifs. Google a toujours été clair sur un point que beaucoup d’articles passent sous silence : ce signal ne surclasse jamais la pertinence et la qualité du contenu. À qualité de réponse équivalente entre deux pages, Google favorise la plus rapide et la plus stable. Les Core Web Vitals ne font donc pas gagner une position à eux seuls, mais ils peuvent en faire perdre lorsqu’ils sont très dégradés, en particulier sur des requêtes concurrentielles où plusieurs résultats répondent aussi bien à l’intention de recherche.
Quels sont les trois Core Web Vitals et leurs seuils recommandés ?
LCP (Largest Contentful Paint) : la vitesse de chargement perçue
Le LCP mesure le temps nécessaire pour afficher le plus grand élément visible dans la zone visible à l’écran au chargement : une image, un titre, un bloc de texte ou une vidéo. C’est l’indicateur qui répond à « combien de temps avant que je voie enfin le contenu que j’étais venu chercher ? ».
- Bon : LCP inférieur ou égal à 2,5 secondes
- À améliorer : entre 2,5 et 4 secondes
- Mauvais : au-delà de 4 secondes
INP (Interaction to Next Paint) : la réactivité
L’INP mesure le délai entre une interaction de l’utilisateur, clic, tap tactile ou saisie clavier, et le moment où le navigateur affiche visuellement le résultat de cette action. Il a remplacé le FID en mars 2024 car il observe toutes les interactions survenues pendant la visite, et pas uniquement la première, ce qui le rend bien plus représentatif d’un parcours complet sur une page riche en JavaScript.
- Bon : INP inférieur ou égal à 200 millisecondes
- À améliorer : entre 200 et 500 millisecondes
- Mauvais : au-delà de 500 millisecondes
CLS (Cumulative Layout Shift) : la stabilité visuelle
Le CLS mesure les déplacements inattendus des éléments visibles pendant le chargement : une image sans dimension réservée qui pousse le texte vers le bas, une bannière de cookies qui apparaît et décale tout le contenu, une police qui charge en retard et change la mise en page. C’est la métrique qui évite le clic malheureux sur le mauvais bouton parce que la page a bougé au moment où le doigt touchait l’écran.
- Bon : CLS inférieur ou égal à 0,1
- À améliorer : entre 0,1 et 0,25
- Mauvais : au-delà de 0,25
Un point que beaucoup de guides oublient de préciser : ces seuils s’évaluent au 75e percentile des visites. Pour qu’une page ou un groupe de pages soit classé « bon » par Google, il faut que 75 % des chargements réels respectent le seuil, mobile et desktop étant toujours évalués séparément. Une page peut donc être excellente sur desktop et mauvaise sur mobile : c’est l’un des cas les plus fréquents, et les outils qui n’affichent qu’un score global le masquent complètement.
Données de terrain vs données de labo : ne mélangez pas les deux
C’est la confusion numéro un sur les Core Web Vitals. Les données de labo (produites par Lighthouse, dans Chrome DevTools ou des outils comme GTmetrix et WebPageTest) mesurent une page au moment du test, sur un réseau et un terminal simulés, dans des conditions contrôlées et reproductibles. Elles sont utiles pour diagnostiquer précisément une page et comparer un avant/après après une correction.
Les données de terrain proviennent du Chrome User Experience Report (CrUX), alimenté par les vraies visites de vrais utilisateurs Chrome, sur leurs vrais appareils et leurs vraies connexions, agrégées sur une fenêtre glissante de 28 jours. C’est cette donnée de terrain, et uniquement elle, que Google utilise comme signal de classement, et c’est elle qui apparaît dans le rapport Core Web Vitals de Google Search Console. Un site peut afficher un LCP excellent en labo et rester classé « à améliorer » dans Search Console pendant un mois après une correction, simplement parce que la fenêtre de 28 jours n’a pas encore intégré les visites postérieures au correctif. Si vous attendez un changement immédiat dans Search Console après une optimisation, vous allez à la déception : comptez environ quatre semaines pour que la donnée de terrain se stabilise entièrement.
Autre nuance utile : CrUX ne fournit des données au niveau d’une URL précise que si cette page reçoit suffisamment de trafic. En dessous d’un certain volume de visites, seules des données agrégées au niveau du domaine (origin) sont disponibles, ce qui explique pourquoi certaines pages à faible trafic n’apparaissent jamais dans le rapport Search Console alors qu’elles existent bel et bien.
Comment vérifier les performances Core Web Vitals de votre site
Plusieurs outils, gratuits pour l’essentiel, permettent de surveiller vos Core Web Vitals, chacun avec un usage différent :
- Google Search Console, rapport « Signaux web essentiels » : la seule source qui reflète la donnée de terrain prise en compte pour le classement, groupée par type de problème, par type d’appareil et par groupes d’URLs similaires.
- PageSpeed Insights : affiche à la fois la donnée de terrain (CrUX, si disponible pour l’URL ou le domaine) et un audit de labo détaillé avec la liste des optimisations suggérées pour chaque métrique.
- Chrome DevTools, onglet Lighthouse ou Performance : pour un diagnostic fin page par page, avec la timeline des tâches JavaScript et le détail des éléments responsables du LCP ou du CLS.
- L’extension Chrome Web Vitals : affiche en temps réel, en surimpression pendant la navigation, les valeurs LCP, INP et CLS mesurées sur votre propre terminal.
- GTmetrix et WebPageTest : utiles pour tester depuis des localisations et des profils réseau différents, et pour visualiser la vidéo du chargement image par image.
- La librairie web-vitals (JavaScript) : à intégrer sur votre site pour collecter vos propres données de terrain (RUM) en temps réel, sans attendre les 28 jours de CrUX, et segmenter par template de page, ce qu’aucun outil externe ne permet de faire.
Pour un diagnostic fiable, croisez toujours Search Console (ce que Google voit réellement) et PageSpeed Insights (pourquoi), plutôt que de piloter vos décisions sur un seul chiffre de labo.
Comment améliorer les performances de vos Core Web Vitals
Améliorer le LCP
- Compressez et servez vos images en formats modernes (WebP, AVIF) à la bonne dimension, jamais plus grandes que leur taille d’affichage réelle.
- Ne mettez jamais l’image principale visible dès le chargement (hero) en lazy loading : c’est l’erreur la plus fréquente, elle retarde exactement l’élément que le LCP mesure. Utilisez plutôt un attribut de priorité de chargement élevée sur cet élément.
- Réduisez le temps de réponse du serveur (TTFB) via la mise en cache, un hébergement adapté ou un CDN.
- Éliminez les ressources CSS et JavaScript bloquantes placées avant le rendu du contenu principal.
- Préchargez la ressource critique de la page (police principale, image hero) plutôt que de laisser le navigateur la découvrir en cours de parsing.
Améliorer l’INP
- Réduisez le volume et le poids du JavaScript exécuté au chargement, en particulier les scripts tiers (chat en ligne, pixels publicitaires, gestionnaires de tags) qui monopolisent le thread principal.
- Découpez les longues tâches JavaScript en plus petits blocs pour laisser le navigateur respirer entre deux interactions.
- Différez le chargement des scripts non indispensables à l’affichage initial, et chargez-les après l’interaction de l’utilisateur plutôt qu’au chargement de la page.
- Évitez les gestionnaires d’événements trop lourds sur les clics et le scroll, qui font tout le travail au moment de l’interaction au lieu de l’anticiper.
Réduire le CLS
- Réservez systématiquement l’espace de vos images et vidéos (dimensions ou ratio d’aspect définis), pour que le navigateur sache où les placer avant même qu’elles soient chargées.
- Réservez l’espace des blocs publicitaires et des contenus embarqués (vidéos, widgets sociaux) avant leur chargement effectif.
- Évitez d’insérer dynamiquement du contenu au-dessus de ce que l’utilisateur est déjà en train de lire, sauf en réponse directe à une de ses actions.
- Utilisez le chargement anticipé des polices avec un comportement d’affichage maîtrisé, pour éviter le changement de mise en page lorsque la police finale remplace la police de secours.
Quelques conseils pour prioriser les correctifs Core Web Vitals
Un audit Core Web Vitals liste souvent dix, vingt, parfois cinquante problèmes. Les corriger dans le désordre est le meilleur moyen de perdre des semaines pour des gains marginaux. La méthode qui fonctionne est une matrice simple impact/effort :
- Priorité 1, les correctifs de template : un header, un footer, un carrousel ou un composant d’image présent sur toutes vos pages. Une seule correction se propage instantanément à des centaines de pages, c’est le meilleur rapport effort/impact possible.
- Priorité 2, les pages à fort trafic ou fort enjeu business : pages d’atterrissage, fiches produits les plus vues, pages de contact ou de devis. Le gain SEO et le gain de conversion s’additionnent.
- Priorité 3, les correctifs spécifiques à une page : à traiter une fois les deux premiers niveaux assainis, sauf si la page concernée génère un chiffre d’affaires significatif à elle seule.
Mesurez chaque correctif en labo immédiatement après déploiement pour valider qu’il fonctionne, puis patientez les quatre semaines nécessaires à la stabilisation de la donnée de terrain avant de juger son effet réel dans Search Console. Corriger un problème puis en conclure un échec après trois jours est une erreur de méthode fréquente, pas un échec technique.
Les erreurs fréquentes qui plombent les Core Web Vitals
- Appliquer un plugin de lazy loading « à toutes les images sans exception », y compris l’image visible dès le chargement, ce qui dégrade le LCP au lieu de l’améliorer.
- Viser un score Lighthouse de 100/100 au détriment de la donnée de terrain réelle, alors que c’est cette dernière qui compte pour Google.
- Empiler des plugins et des extensions sur un CMS sans mesurer leur coût en JavaScript cumulé, chacun semblant léger isolément mais tous ensemble alourdissant fortement l’INP.
- Ne regarder que le segment desktop dans un audit, alors que la majorité du trafic, et des problèmes, se situe sur mobile.
- Conclure trop vite après une correction, avant la fin de la fenêtre de 28 jours de CrUX.
Le cas particulier de WordPress
Sur WordPress, qui équipe une grande partie des sites de TPE et PME, les problèmes de Core Web Vitals viennent presque toujours des mêmes sources : un thème ou un constructeur de pages (Elementor, Divi) qui charge son propre CSS et JavaScript sur chaque page même quand ils sont inutilisés, une accumulation de plugins non indispensables, et des images importées depuis le back-office sans redimensionnement ni compression. Un plugin de cache et de minification correctement configuré, couplé à un nettoyage des plugins réellement utilisés et à une politique stricte sur les images, règle à lui seul une majorité des problèmes de LCP et d’INP observés sur ce type de site, avant même d’envisager un changement de thème ou d’hébergement.
En conclusion
Les Core Web Vitals ne sont ni un gadget technique réservé aux développeurs, ni un levier miracle de référencement. Ce sont trois métriques concrètes, LCP, INP et CLS, qui traduisent en chiffres ce que vos visiteurs ressentent à chaque visite, et que Google utilise comme un signal parmi d’autres dans son classement. La bonne méthode consiste à mesurer sur la donnée de terrain disponible dans Search Console, diagnostiquer en labo avec PageSpeed Insights, corriger en priorité les éléments de template qui touchent le plus de pages, puis laisser le temps à la donnée de terrain de refléter vos efforts avant d’en tirer des conclusions.
Notre expertise en référencement Google à votre service
Chez Effet Papillon, nous intégrons systématiquement l’audit des Core Web Vitals dans nos accompagnements SEO, parce qu’un contenu pertinent qui se charge lentement ou qui bouge sous les doigts de vos visiteurs perd une partie de son potentiel. Si vous voulez savoir précisément où se situent vos pages sur LCP, INP et CLS, et dans quel ordre agir pour un résultat mesurable, notre équipe peut réaliser cet audit technique et vous accompagner sur les correctifs prioritaires.
FAQ
Qu’est-ce que Core Web Vitals ?
Les Core Web Vitals sont trois métriques définies par Google, LCP, INP et CLS, qui mesurent respectivement la vitesse de chargement perçue, la réactivité aux interactions et la stabilité visuelle d’une page web. Elles font partie du signal « expérience de page » pris en compte dans le classement des résultats de recherche.
Comment analyser les performances d’un site web ?
La méthode la plus fiable consiste à croiser deux sources : le rapport « Signaux web essentiels » de Google Search Console pour connaître la donnée de terrain réellement prise en compte par Google, et PageSpeed Insights ou Chrome DevTools pour obtenir un diagnostic de labo détaillé expliquant quels éléments techniques pénalisent chaque métrique sur une page précise.
Quel est l’outil qui mesure les Core Web Vitals d’une page ?
PageSpeed Insights est l’outil de référence de Google : il affiche à la fois la donnée de terrain issue du Chrome User Experience Report, lorsqu’elle est disponible pour l’URL, et un audit de labo basé sur Lighthouse avec des recommandations détaillées. Pour la donnée de terrain agrégée par Google à l’échelle du site, c’est le rapport Core Web Vitals de Google Search Console qui fait référence.
