Core Web Vitals : ce qu'ils mesurent et comment les corriger

Que sont les Core Web Vitals et pourquoi Google les mesure-t-il ?

Les Core Web Vitals sont trois métriques créées par Google pour évaluer l'expérience utilisateur sur une page web : le LCP pour la vitesse de chargement, l'INP pour la réactivité, et le CLS pour la stabilité visuelle. Chacune a un seuil « Bon » précis, repris dans le tableau ci-dessous.

Google a présenté les Core Web Vitals en 2020, dans le cadre d'un ensemble plus large de signaux appelés Page Experience. Ces métriques sont devenues un facteur de classement effectif dans les résultats de recherche mi-2021, avec le déploiement du Page Experience update. Elles s'appliquent aussi bien au mobile qu'au desktop, avec des seuils identiques pour les deux.

Ces trois métriques ne sont pas un sujet réservé aux développeurs. Elles se lisent comme un thermomètre de l'expérience que vit un visiteur sur votre site avant même d'avoir lu une ligne de contenu : temps d'attente, réactivité aux clics, stabilité de la mise en page. Un site qui échoue sur les trois peut afficher le meilleur contenu du marché, l'expérience vécue reste dégradée.

Pourquoi l'INP a-t-il remplacé le FID en 2024 ?

Depuis le 12 mars 2024, l'Interaction to Next Paint (INP) remplace officiellement le First Input Delay (FID) comme métrique de réactivité des Core Web Vitals (annonce officielle de Google Search Central).

Le FID ne mesurait que le délai avant la toute première interaction de l'utilisateur avec la page, comme le premier clic sur un bouton ou un menu. C'était une mesure instantanée, prise une seule fois, qui ne disait rien de la réactivité du reste de la session. L'INP, lui, observe toutes les interactions de la visite (clics, appuis tactiles, saisies clavier) et retient la pire d'entre elles pour représenter la réactivité réelle de la page, du premier au dernier clic.

Ce changement n'est pas anecdotique. Une page peut très bien répondre vite au premier clic et ralentir ensuite, par exemple quand un plugin de chat se charge en arrière-plan ou qu'un formulaire devient lourd à remplir. Le FID ne détectait jamais ce cas de figure, l'INP le mesure sur toute la session. Si vous consultez encore un contenu qui présente le FID comme une métrique active des Core Web Vitals, il décrit une version du sujet dépassée depuis plus de deux ans.

Comment mesurer les Core Web Vitals de votre site ?

Deux outils gratuits suffisent pour mesurer les Core Web Vitals de la majorité des sites : PageSpeed Insights pour un diagnostic ponctuel, et Google Search Console pour suivre leur évolution dans le temps.

PageSpeed Insights

PageSpeed Insights combine deux types de données : une mesure de laboratoire (le chargement de votre page dans un environnement contrôlé) et, quand le trafic du site le permet, une donnée réelle issue des visiteurs Chrome (le Chrome User Experience Report, ou CrUX). C'est l'outil le plus simple pour un non-développeur : vous collez une URL, l'outil renvoie un score et le détail des trois métriques, avec les points qui posent problème. Il est gratuit et ne demande aucun accès technique au site.

Google Search Console

Le rapport « Signaux Web Essentiels » de Search Console regroupe vos pages par lot d'URL similaires et affiche leur statut (Bon, À améliorer, Mauvais) pour chaque métrique, avec un historique dans le temps. C'est la seule vue qui permet de voir si une correction a réellement fait progresser le nombre de pages en bon état, plutôt qu'une mesure isolée sur une seule URL. Pour aller plus loin dans le diagnostic technique, notre article sur l'audit SEO complet détaille comment lire l'ensemble des rapports Search Console.

Chrome DevTools et Lighthouse

Chrome DevTools intègre l'outil Lighthouse, qui donne un diagnostic détaillé : poids de chaque ressource, scripts bloquants, éléments responsables du décalage visuel. C'est un outil pensé pour un développeur ou une agence technique, pas pour un usage quotidien côté direction : il sert surtout à identifier la cause exacte d'un problème une fois qu'il a été repéré via PageSpeed Insights ou Search Console.

Comment améliorer le LCP (temps de chargement) ?

Trois leviers concentrent l'essentiel du gain sur le Largest Contentful Paint (LCP) : la qualité de l'hébergement, le poids des images, et la mise en cache. Les corriger dans cet ordre couvre la majorité des cas rencontrés en audit.

• Un hébergement de qualité, si possible localisé en France : un serveur mutualisé bas de gamme ou éloigné de votre audience ajoute plusieurs centaines de millisecondes avant même que la page ne commence à s'afficher. Un VPS ou un serveur dédié, aux ressources non partagées, réduit ce délai de départ.
• Des images compressées et au bon format : redimensionnez chaque image à sa taille d'affichage réelle avant la mise en ligne, et utilisez un format moderne comme le WebP plutôt que le JPEG ou le PNG. Le LCP retient le plus grand élément visible au premier écran, qu'il s'agisse d'une image, d'un titre ou d'un bloc vidéo : optimiser cet élément agit directement sur la métrique.
• La mise en cache : un navigateur qui garde en mémoire le logo, les feuilles de style et les scripts déjà vus lors d'une visite précédente n'a pas besoin de les retélécharger. Sur WordPress, des extensions comme WP Rocket ou W3 Total Cache activent ce réglage en quelques clics. Sur les autres types de sites, la mise en cache se configure côté serveur.
• La compression et la minification des fichiers CSS et JavaScript : la compression GZIP (ou son équivalent plus récent, Brotli) réduit le poids des fichiers transférés par le serveur, tandis que la minification retire les espaces et commentaires inutiles du code. Ces deux réglages se configurent au niveau de l'hébergeur ou via une extension, sans intervention sur le design du site.

Un piège à éviter : ne jamais appliquer le chargement différé (lazy loading) à l'image principale de la page, celle qui est visible sans avoir à faire défiler l'écran. Le lazy loading retarde volontairement le chargement d'une image tant qu'elle n'est pas visible : appliqué à l'élément que mesure justement le LCP, il dégrade la métrique au lieu de l'améliorer. Réservez cette technique aux images situées plus bas dans la page.

Comment améliorer l'INP (réactivité) ?

La cause la plus fréquente d'un mauvais Interaction to Next Paint (INP) est un script tiers qui monopolise le navigateur au moment où l'utilisateur clique : chat en ligne, pixel marketing, ou plugin de formulaire trop lourd.

Trois catégories de causes techniques sont à vérifier en priorité : les widgets de chat et de support client, les scripts de tracking marketing (pixels publicitaires, multiples outils d'analytics), et les plugins de formulaire qui exécutent une validation lourde à chaque champ rempli. Chacun de ces éléments s'exécute en JavaScript et occupe le navigateur au moment précis où l'utilisateur tente d'interagir avec la page.

Corriger cela ne demande pas nécessairement de renoncer à ces outils, mais de revoir la façon dont ils se chargent : différer leur exécution après l'affichage du contenu principal, limiter le nombre de scripts tiers actifs simultanément, ou remplacer un plugin de formulaire lourd par une version plus légère. C'est un travail plus technique que les corrections du LCP, qui gagne à être confié à un développeur ou traité dans le cadre d'un accompagnement SEO technique.

Comment améliorer le CLS (stabilité visuelle) ?

La cause la plus fréquente d'un mauvais Cumulative Layout Shift (CLS) est un espace non réservé à l'avance : une bannière de consentement aux cookies qui s'affiche après le reste de la page, ou une image sans dimensions définies qui pousse le contenu au moment où elle se charge.

• Définir la largeur et la hauteur de chaque image et vidéo dans le code de la page, avant même que le fichier ne soit chargé. Le navigateur réserve ainsi l'espace nécessaire dès le départ, et le contenu autour ne bouge plus une fois l'image affichée.
• Réserver l'espace de la bannière de consentement aux cookies dans la mise en page, plutôt que de l'insérer après coup par-dessus le contenu déjà affiché. C'est l'une des causes de décalage les plus visibles pour un visiteur, car elle survient dès l'arrivée sur la page.
• Contrôler le chargement des polices personnalisées : par défaut, un navigateur peut afficher un texte invisible le temps qu'une police se charge, puis le faire réapparaître dans une police différente, ce qui déplace le contenu autour. Le réglage `font-display: swap` affiche une police de substitution dès le départ, puis bascule discrètement vers la police définitive une fois chargée, sans décalage brutal.

Les Core Web Vitals font-ils vraiment baisser vos positions Google ?

Les Core Web Vitals sont un facteur de classement Google depuis mi-2021, mais un facteur secondaire : ils départagent des pages dont le contenu répond déjà de façon comparable à une recherche, ils ne compensent pas un contenu faible ni ne remplacent la pertinence éditoriale.

Concrètement, entre deux pages qui traitent un sujet avec un niveau de qualité équivalent, celle qui offre la meilleure expérience technique (chargement rapide, réactivité, stabilité) a un avantage. Entre une page de contenu solide mais lente, et une page de contenu faible mais rapide, Google continue de privilégier la pertinence du contenu. Les Core Web Vitals ne sauvent pas un mauvais contenu, ils départagent des contenus de qualité comparable.

L'enjeu business derrière la vitesse dépasse d'ailleurs le seul classement Google. Une étude Google/SOASTA menée en 2017 sur le mobile mesurait que 53 % des visiteurs quittaient une page qui mettait plus de 3 secondes à charger, et que le risque d'abandon augmentait de 113 % entre 1 et 7 secondes de chargement. Cette étude date d'avant l'existence même des Core Web Vitals, mais elle illustre une réalité qui n'a pas changé depuis : la vitesse perçue influence directement le comportement, indépendamment du classement dans les résultats de recherche.

Pour savoir où se situe votre site sur ces trois métriques et sur l'ensemble des facteurs techniques du référencement, un audit SEO complet donne une vue précise plutôt qu'une estimation.

Par où commencer selon votre site (WordPress, e-commerce, vitrine) ?

Le point de départ dépend du type de site : un site WordPress gagne d'abord sur le cache et les extensions, un site e-commerce sur l'image produit et les scripts tiers, un site vitrine simple sur l'hébergement et le poids des images.

Site WordPress

Sur WordPress, la cause la plus courante d'un mauvais score tient à l'accumulation d'extensions et à l'absence de cache actif. Chaque plugin installé charge son propre code, même sur des pages où il ne sert à rien : un tri régulier des extensions, combiné à une extension de cache (WP Rocket, W3 Total Cache), corrige une bonne partie des cas avant même de toucher au thème. Notre offre SEO WordPress intègre ce diagnostic technique dans l'accompagnement.

Site e-commerce

Sur une boutique en ligne, deux points concentrent l'attention : l'image du produit principal, l'élément que le LCP mesure sur une fiche produit type, et les scripts tiers (avis clients, recommandations, chat de vente), qui pèsent sur l'INP. Traiter ces deux points avant d'optimiser le reste du catalogue donne le gain le plus visible. Une offre SEO e-commerce dédiée permet de traiter ces points fiche par fiche plutôt que sur l'ensemble du catalogue d'un coup.

Site vitrine simple

Pour un site vitrine, sans forte volumétrie de pages ni de scripts tiers nombreux, l'hébergement et le poids des images restent les deux leviers à traiter en priorité, avant d'envisager une intervention plus technique sur le code.

Le choix du CMS pèse aussi sur le point de départ : Webflow génère par défaut un code optimisé pour la performance, quand WordPress demande davantage d'entretien technique (cache, plugins, poids des images) pour obtenir un résultat comparable. Notre comparatif Webflow et WordPress détaille ces différences si vous hésitez encore entre les deux plateformes.

Questions fréquentes sur les Core Web Vitals

Le score PageSpeed Insights et les Core Web Vitals sont-ils la même chose ?

Non. PageSpeed Insights est un outil de mesure qui affiche un score global sur 100, calculé à partir de plusieurs signaux techniques, dont les Core Web Vitals font partie sans en être les seuls composants. Un site peut avoir un score PageSpeed Insights correct sans passer les trois métriques Core Web Vitals, et inversement. Pour vérifier spécifiquement les Core Web Vitals, il faut regarder les valeurs LCP, INP et CLS affichées dans le détail du rapport, ou consulter directement le rapport Signaux Web Essentiels de Search Console.

WordPress est-il pénalisé par défaut sur les Core Web Vitals ?

Non, WordPress en lui-même n'est pas pénalisé par Google : c'est un CMS parmi d'autres, sans traitement différencié dans le classement. Ce qui pèse sur les scores, c'est l'accumulation d'extensions, un thème mal optimisé ou l'absence de mise en cache, des réglages qui dépendent de la configuration du site et non du CMS lui-même. Un WordPress bien configuré passe les trois métriques sans difficulté particulière.

Combien de temps faut-il pour corriger ses Core Web Vitals ?

Cela dépend de la cause identifiée. Un problème d'image mal compressée ou de cache désactivé se corrige en quelques heures. Un problème lié à des scripts tiers nombreux ou à un hébergement sous-dimensionné demande davantage de temps, et parfois un changement d'infrastructure. Une fois la correction en ligne, Google Search Console reflète l'amélioration dans un délai de 28 jours, la fenêtre de mesure utilisée pour calculer le statut de chaque page.

Un mauvais score Core Web Vitals fait-il disparaître une page de Google ?

Non. Un mauvais score sur les Core Web Vitals dégrade un facteur de classement parmi d'autres, il ne provoque pas de désindexation ni de pénalité au sens strict. Une page peut se positionner avec des Core Web Vitals dans le rouge si son contenu répond mieux à la recherche que la concurrence. Cela dit, corriger ces métriques reste un levier direct et mesurable, contrairement à d'autres facteurs de classement plus difficiles à isoler.

Faut-il être développeur pour améliorer ses Core Web Vitals ?

Pas pour l'ensemble des corrections. Le poids des images, la mise en cache, la compression des fichiers ou la mesure via PageSpeed Insights et Search Console sont accessibles sans écrire de code, notamment via les extensions disponibles sur WordPress. Les corrections liées à l'INP (scripts tiers, plugins de formulaire) et certains ajustements du CLS liés au code du thème demandent en revanche une intervention technique, en interne ou dans le cadre d'un accompagnement SEO dédié.

Passer à l'action sur vos Core Web Vitals

Corriger les Core Web Vitals n'est pas un chantier ponctuel : chaque changement sur le site (nouveau plugin, nouvelle bannière, nouvelle image) peut faire repasser une métrique dans le rouge. La bonne pratique est de vérifier le rapport Signaux Web Essentiels de Search Console à intervalles réguliers, plutôt que de considérer le sujet clos après une première série de corrections.

Chez Komtop, la vérification des Core Web Vitals fait partie du diagnostic technique de nos audits. Quand les corrections dépassent le réglage d'une extension (scripts tiers, structure du thème, infrastructure d'hébergement), elles s'intègrent dans un accompagnement SEO qui traite la performance technique aux côtés du contenu et du netlinking.