Temps de lecture : 10 minutes | Mis a jour : mars 2026
Qu'est-ce que les Core Web Vitals ?
Les Core Web Vitals sont un ensemble de trois metriques définies par Google pour mesurer la qualité de l'expérience utilisateur sur une page web. Introduites en 2020 et intégrées comme facteur de classement en 2021, elles evaluent trois dimensions fondamentales de la performance web : la vitesse de chargement du contenu principal, la réactivité aux interactions de l'utilisateur et la stabilite visuelle de la page.
Les trois metriques sont :
- LCP (Largest Contentful Paint) : mesure le temps de chargement du plus grand element visible dans la fenetre du navigateur.
- INP (Interaction to Next Paint) : mesure le temps de réponse du site aux actions de l'utilisateur (clics, appuis, saisie clavier). A remplacé le FID (First Input Delay) en mars 2024.
- CLS (Cumulative Layout Shift) : mesure les deplacements inattendus des elements de la page pendant le chargement.
Ces trois indicateurs forment le socle du SEO technique moderne. Google ne se contente plus d'évaluer la pertinence de votre contenu : il juge aussi la qualité de l'expérience que votre site offre a ses visiteurs. Un site avec un contenu excellent mais une performance mediocre sera desavantage face a un concurrent qui proposé les deux.
| Metrique | Bon | A améliorer | Mediocre |
|---|---|---|---|
| LCP | ≤ 2,5 secondes | 2,5 - 4 secondes | > 4 secondes |
| INP | ≤ 200 millisecondes | 200 - 500 millisecondes | > 500 millisecondes |
| CLS | ≤ 0,1 | 0,1 - 0,25 | > 0,25 |
LCP (Largest Contentful Paint) : la vitesse de chargement perceptible
Le LCP mesure le temps que met le plus grand element visible de la page a s'afficher complètement dans la fenetre du navigateur. Cet element est généralement l'image hero d'une page d'accueil, un bloc de texte principal, ou une image produit sur une fiche e-commerce. C'est la metrique qui reflète le mieux ce que l'utilisateur ressent : tant que le LCP n'est pas affiche, le visiteur a l'impression que la page "n'a pas encore charge".
Cible : un LCP inférieur a 2,5 secondes sur mobile et desktop.
Les causes fréquentes d'un mauvais LCP
- TTFB (Time to First Byte) élève : le serveur met trop de temps a répondre. Sans caché page ou CDN (Content Delivery Network), chaque requete traverse la pile PHP/MySQL complète. Sur un site sans caché, le TTFB dépasse souvent 1 seconde a lui seul -- ce qui laisse moins de 1,5 seconde pour charger tout le reste.
- Image hero non optimisée : une image de 500 Ko au format JPEG classique, sans dimensions explicites, sans preload. Le navigateur la découvre tardivement et la télécharge lentement.
- CSS render-blocking : des feuilles de style externes volumineuses (80+ Ko) qui bloquent le rendu tant qu'elles ne sont pas complètement telechargees. Si elles contiennent un
@importvers Google Fonts, la cascade de chargement s'allonge encore. - Lazy loading sur l'image hero : une erreur classique. L'image principale au-dessus du pli ne doit jamais être en chargement diffère -- elle doit se charger immediatement avec
fetchpriority="high".
Comment améliorer le LCP
- Activez le caché page sur votre serveur (LiteSpeed Caché, WP Rocket, Cloudflare caché). C'est le levier le plus puissant : le TTFB peut passer de 1 seconde a moins de 200 millisecondes.
- Utilisez un CDN comme Cloudflare ou QUIC.cloud pour servir le contenu depuis un serveur geographiquement proche de vos visiteurs.
- Optimisez l'image LCP : convertissez-la en WebP ou AVIF, compressez-la sous 100 Ko, ajoutez
fetchpriority="high"et un<link rel="preload">dans le<head>. - Eliminez les CSS render-blocking : inlinez le CSS critique (au-dessus du pli), differez le reste, supprimez le CSS inutilise (technique UCSS -- Unused CSS).
Chez Transacts, quand nous prenons en charge l'optimisation d'un site client, le LCP est le premier indicateur que nous ciblons. C'est celui qui a le plus d'impact perceptible pour les visiteurs et le plus de poids dans les Core Web Vitals. En plus de 25 ans d'expérience, nous constatons que le caché serveur et l'optimisation de l'image hero corrigent a eux seuls 80 % des problèmes de LCP.
INP (Interaction to Next Paint) : la réactivité du site
L'INP a remplacé le FID (First Input Delay) en mars 2024 comme metrique officielle d'interactivite des Core Web Vitals. Contrairement au FID qui ne mesurait que la première interaction, l'INP mesure la réactivité de la page sur l'ensemble de la session de navigation. C'est une évaluation bien plus realiste : un site peut être réactif au premier clic mais devenir lent une fois que les scripts lourds s'executent en arrière-plan.
Cible : un INP inférieur a 200 millisecondes.
Les causes fréquentes d'un mauvais INP
- JavaScript synchrone trop lourd : des scripts qui bloquent le thread principal du navigateur pendant plusieurs centaines de millisecondes. Les thèmes WordPress premium (Salient, Divi, Avada) chargent parfois 500 a 800 Ko de JavaScript -- soit 30 scripts ou plus sur une seule page.
- Scripts tiers non maîtrisés : widgets de chat en direct, popups de consentement cookies charges en synchrone, boutons de réseaux sociaux, scripts analytics redondants (par exemple, un ancien Google Analytics UA toujours charge a côté de GA4). Chaque script ajouté quelques dizaines de millisecondes qui s'accumulent.
- Event listeners excessifs : des gestionnaires d'événements attaches a des centaines d'elements du DOM, souvent generes automatiquement par des constructeurs de pages visuels (WPBakery, Elementor, Divi).
Comment améliorer l'INP
- Differez les scripts non-critiques : ajoutez l'attribut
deferouasyncsur les scripts JavaScript qui ne sont pas nécessaires au premier affichage. Le bandeau cookies, l'analytics, les widgets sociaux peuvent attendre. - Identifiez et decoupez les "Long Tasks" : ouvrez l'onglet Performance de Chrome DevTools, enregistrez une session, et repererez les taches qui bloquent le thread principal pendant plus de 50 millisecondes. Fractionnez-les en opérations plus courtes.
- Supprimez les scripts morts : anciens scripts Google Analytics UA (obsolete depuis 2023), scripts Wysistat, anciennes versions de jQuery chargees en doublon, plugins desactives mais dont le JS est toujours enfile. Chaque script supprimé libère du temps processeur.
- Reduisez la taille du DOM : un DOM de plus de 1 500 elements ralentit chaque manipulation JavaScript. Simplifiez la structure HTML, supprimez les conteneurs imbriques inutiles generes par les page builders.
L'INP est la metrique la plus difficile a optimiser car elle dépend directement de la qualité et du volume du code JavaScript execute sur la page. La priorite est de traiter les scripts tiers et les Long Tasks avant de s'attaquer a l'architecture JavaScript du thème lui-même.
CLS (Cumulative Layout Shift) : la stabilite visuelle de la page
Le CLS mesure la quantite de deplacements inattendus du contenu visible pendant le chargement. Vous avez certainement déjà vecu cette situation : vous commencez a lire un texte, et soudain le paragraphe se decale vers le bas parce qu'une image ou une banniere publicitaire vient de se charger au-dessus. C'est exactement ce que le CLS quantifie. Plus le score est bas, plus la page est visuellement stable.
Cible : un CLS inférieur a 0,1.
Les causes fréquentes d'un mauvais CLS
- Images sans dimensions explicites : quand une balise
<img>ne declare pas ses attributswidthetheight, le navigateur ne sait pas quelle place réserver. Quand l'image arrivé, le contenu en dessous se decale brutalement. - Publicités et embeds charges dynamiquement : les iframes publicitaires, les vidéos YouTube, les widgets de réseaux sociaux injectes après le premier rendu poussent le contenu existant vers le bas.
- Polices web chargees tardivement : quand une police custom se charge après le texte, le texte est d'abord affiche dans une police de substitution (avec des dimensions différentes), puis il "saute" lorsque la police definitive est appliquee. C'est le FOUT (Flash of Unstyled Text).
- Sliders et carousels : les diaporamas qui changent de hauteur selon le contenu de la slide active provoquent des shifts a chaque transition.
Comment améliorer le CLS
- Declarez width et height sur toutes vos images : c'est la correction la plus simple et la plus efficace. Le navigateur réservé l'espace exact avant même que l'image ne soit telechargee. Ajoutez aussi la propriete CSS
aspect-ratiopour les mises en page responsives. - Reservez l'espace pour les publicités : utilisez des conteneurs avec une hauteur minimale fixe (
min-height) pour les emplacements publicitaires et les embeds. - Ajoutez
font-display: swapa vos declarations@font-facepour que le texte reste lisible pendant le chargement de la police, avec une transition douce vers la police definitive. - Evitez les injections dynamiques au-dessus du pli : les bannieres, barres de notification et popups qui poussent le contenu vers le bas doivent être chargees immediatement ou positionnees en
position: fixedpour ne pas affecter le flux de la page.
Le CLS est souvent la metrique la plus facile a corriger. Ajouter les dimensions des images et réserver l'espace pour les elements dynamiques suffit a passer sous le seuil de 0,1 dans la grande majorite des cas.
Outils pour mesurer les Core Web Vitals
Google met a disposition plusieurs outils gratuits pour mesurer les Core Web Vitals. La distinction essentielle a comprendre est celle entre les données "terrain" (mesurees sur de vrais utilisateurs de Chrome) et les données "labo" (simulees dans un environnement contrôle). Google utilisé les données terrain pour déterminer ses classements.
| Outil | Type de données | Ce qu'il mesure | Quand l'utiliser |
|---|---|---|---|
| PageSpeed Insights | Terrain + Labo | Les 3 CWV avec seuils, données CrUX (Chrome User Expérience Report) et audit Lighthouse complet. | Première analyse d'un site. Vue d'ensemble rapide et fiable. |
| Google Search Console | Terrain | Onglet "Signaux Web essentiels" : LCP, INP et CLS sur l'ensemble de vos pages, classés en "Bon", "A améliorer", "Mediocre". | Suivi dans le temps. Identification des pages problématiques a grande échelle. |
| Google Lighthouse | Labo | Audit complet : performance, accessibilite, bonnes pratiques, SEO. Score sur 100 avec recommandations détaillées. | Diagnostic technique approfondi. Identification des causes précises. |
| Chrome UX Report (CrUX) | Terrain | Données agregees des utilisateurs réels de Chrome sur 28 jours glissants. C'est la source de vérité pour Google. | Comparaison avec les concurrents. Analyse de tendances. |
| Chrome DevTools (Performance) | Labo | Profil d'execution détaillé : timeline, Long Tasks, waterfall des ressources, flamegraph JavaScript. | Debug avancé. Identification précise des scripts et ressources problématiques. |
Notre conseil : commencez par PageSpeed Insights pour obtenir la vue globale (terrain + labo). Puis consultez Google Search Console pour identifier les pages spécifiques qui echouent. Enfin, utilisez Lighthouse et DevTools sur ces pages pour diagnostiquer les causes précises et appliquer les corrections. Les données terrain se mettent a jour tous les 28 jours -- prevoyez un cycle de 4 a 8 semaines pour voir l'impact de vos corrections dans le CrUX.
L'impact des Core Web Vitals sur le SEO
Les Core Web Vitals sont un facteur de classement confirme de Google depuis juin 2021. Mais leur poids dans l'algorithme est souvent mal compris. Google l'a dit clairement : le contenu reste le signal le plus important. A contenu égal entre deux pages concurrentes, la performance fait la différence. Les CWV sont un critere de departage, pas un critere dominant.
L'impact indirect est cependant considérable. Un site lent génère un taux de rebond plus élève : selon Google, 53 % des visiteurs mobiles quittent une page qui met plus de 3 secondes a charger. Ce comportement envoie un signal négatif a l'algorithme. Un site instable visuellement (CLS élève) frustre les utilisateurs qui cliquent par erreur sur un element mal place, puis reviennent dans les résultats de recherche -- ce que Google interprete comme un signal d'insatisfaction.
A l'inverse, un site rapide et stable garde les visiteurs plus longtemps. Le temps passe sur le site augmenté, le taux de rebond diminue, et le taux de conversion progresse. Ces signaux d'engagement positifs renforcent le positionnement dans la durée.
Chez Transacts, nous integrons l'optimisation des Core Web Vitals dans chaque projet de création ou de maintenance de site web. Ce n'est pas un bonus technique réservé aux sites a fort trafic : c'est un prealable a toute stratégie SEO qui vise des résultats durables. Depuis plus de 25 ans, nous avons vu l'impact direct de ces optimisations sur le positionnement et la conversion de nos clients.
Questions fréquentes sur les Core Web Vitals
Les Core Web Vitals sont-ils un facteur de ranking Google ?
Oui, depuis juin 2021. Les Core Web Vitals font partie des signaux d'expérience de page utilisés par Google pour classer les résultats de recherche. Ce n'est pas le facteur le plus puissant -- le contenu, les liens et la pertinence de la page restent dominants. Mais a contenu équivalent entre deux pages concurrentes, celle qui offre de meilleurs CWV sera favorisee. C'est un critere de departage qui peut faire la différence sur les requetes competitives.
Comment mesurer les Core Web Vitals ?
Trois outils gratuits couvrent l'essentiel. PageSpeed Insights (pagespeed.web.dev) fournit a la fois les données terrain (mesurees sur de vrais utilisateurs Chrome) et les données labo. Google Search Console (onglet "Signaux Web essentiels") donné une vue d'ensemble de toutes les pages de votre site avec un classement par statut. Lighthouse (dans Chrome DevTools, touche F12) fournit un audit technique détaillé avec des recommandations précises. Les données terrain (CrUX) sont celles que Google utilisé réellement pour son classement -- elles comptent plus que les données labo.
Quel est le Core Web Vital le plus important ?
Le LCP (Largest Contentful Paint). C'est la metrique qui a le plus d'impact perceptible sur l'expérience utilisateur : tant que l'element principal de la page n'est pas affiche, le visiteur a l'impression que le site est en panne. C'est aussi la metrique la plus souvent en échec -- un LCP au-dessus de 2,5 secondes est fréquent sur les sites qui n'ont ni caché serveur ni CDN. La bonne nouvelle : c'est souvent la metrique la plus facile a améliorer. Activer un caché page peut suffire a passer sous le seuil.
Comment améliorer rapidement ses Core Web Vitals ?
Trois corrections rapides couvrent la majorite des problèmes. Pour le LCP : activez un caché serveur (WP Rocket, LiteSpeed Caché) ou un CDN (Cloudflare). Le TTFB passe de 1 seconde a moins de 200 millisecondes, ce qui amélioré directement le LCP. Pour le CLS : ajoutez les attributs width et height sur toutes vos images pour que le navigateur réservé l'espace avant le chargement. Pour l'INP : differez les scripts non-critiques avec l'attribut defer pour libérer le thread principal du navigateur et améliorer la réactivité aux clics.
