Un site qui charge lentement ou qui bouge sous les doigts perd des visiteurs avant même qu’ils lisent la première ligne. Les Core Web Vitals mesurent exactement ça : la vitesse perçue, la réactivité et la stabilité visuelle d’une page. Google les utilise comme signal de classement et beaucoup d’équipes les découvrent seulement quand le trafic recule. Voici ce qu’il faut corriger, dans quel ordre, pour arrêter l’hémorragie.
En bref
Les Core Web Vitals regroupent trois indicateurs Google : LCP (vitesse de chargement), INP (réactivité aux interactions) et CLS (stabilité visuelle), mesurés sur de vrais visiteurs. Un site qui échoue sur l’un de ces critères perd du trafic organique et voit ses taux de conversion baisser, en particulier sur mobile.
La correction suit toujours le même ordre : diagnostiquer avec des données réelles, isoler l’indicateur le plus dégradé, puis traiter les images, le JavaScript et les polices avant d’optimiser le reste.
Que mesurent les Core Web Vitals de Google
Les Core Web Vitals sont un jeu de trois métriques publiées par Google pour évaluer l’expérience réelle vécue sur une page web. Chacune répond à une question précise que se pose un visiteur, même sans le formuler : est-ce que ça charge vite, est-ce que ça répond quand je clique, est-ce que la mise en page reste stable pendant le chargement.
Ces Core Web Vitals font partie des signaux d’expérience de page utilisés dans le classement, aux côtés de la sécurité du site et de l’absence d’interstitiels intrusifs. Google Search Central documente précisément leur mode de calcul et leurs seuils officiels, ce qui en fait une référence plus fiable que les estimations d’outils tiers.
Le point souvent mal compris : ces mesures viennent de données de terrain, collectées sur les visiteurs réels via le Chrome User Experience Report, et non d’un test en laboratoire isolé. Un site peut donc paraître rapide dans un audit ponctuel et rester classé « à améliorer » dans Search Console.
LCP, INP, CLS : les seuils des Core Web Vitals à connaître
Chaque métrique a un seuil « bon » défini par Google, mesuré au 75e centile des chargements de page, mobile et desktop confondus. En dessous de ce seuil, la page est considérée comme performante pour la majorité des visiteurs.
| Indicateur | Ce qu’il mesure | Seuil « bon » | Cause fréquente si dégradé |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Temps d’affichage du plus grand élément visible | ≤ 2,5 s | Image hero non optimisée, serveur lent, police bloquante |
| INP (Interaction to Next Paint) | Délai entre un clic et la réponse visuelle | ≤ 200 ms | JavaScript trop lourd, scripts tiers bloquants |
| CLS (Cumulative Layout Shift) | Somme des déplacements inattendus de la mise en page | ≤ 0,1 | Images sans dimensions, bannière injectée tardivement |
L’INP a remplacé le FID en mars 2024 comme métrique officielle de réactivité, un changement documenté par Google et qui a fait basculer certains sites d’un statut « bon » à « à améliorer » sans qu’aucun code n’ait changé sur la page.
L’impact des Core Web Vitals sur le trafic et les conversions
Un site sous les seuils recommandés ne s’effondre pas dans les classements du jour au lendemain, mais il perd un avantage face à des concurrents qui, à contenu équivalent, offrent une meilleure expérience de page.
L’effet le plus mesurable se voit sur les conversions plutôt que sur le classement pur. Un LCP qui dépasse 4 secondes fait fuir une partie des visiteurs mobiles avant l’affichage du formulaire ou de la fiche produit. Un CLS élevé provoque des clics accidentels, notamment sur les boutons d’achat ou d’inscription, qui frustrent l’utilisateur et gonflent le taux de rebond.
Ce sujet dépasse le seul référencement : c’est un problème d’infrastructure et de code qui relève souvent d’un diagnostic technique plutôt que d’un simple ajustement de contenu. Traiter la performance comme un chantier IT, avec des priorités et une mesure avant/après, donne des résultats plus durables qu’une série de correctifs ponctuels.
Diagnostiquer ses Core Web Vitals avant de corriger
Deux sources de données se complètent et il faut les croiser avant d’agir. PageSpeed Insights et l’outil Lighthouse de Google donnent un diagnostic en laboratoire, page par page. Le rapport « Signaux Web essentiels » de Search Console donne, lui, les données de terrain agrégées par groupe d’URL, sur les vrais visiteurs des 28 derniers jours.
Commencer par Search Console pour repérer les groupes de pages en échec, puis descendre dans Lighthouse pour comprendre la cause exacte sur un gabarit représentatif.
Ce travail de cadrage rejoint celui d’un audit SEO/GEO complet, où la performance technique n’est qu’un chapitre parmi la structure des balises, le maillage et les données structurées, comme détaillé dans notre checklist d’audit SEO/GEO.
La méthode pour corriger les trois Core Web Vitals
Chaque indicateur appelle des corrections différentes, souvent indépendantes les unes des autres.
- Pour le LCP : compresser et redimensionner l’image ou l’élément principal, le précharger avec
fetchpriority="high", et réduire le temps de réponse serveur. - Pour l’INP : découper le JavaScript en tâches plus courtes, différer les scripts tiers non essentiels (chat, trackers marketing) et limiter le travail exécuté au premier clic.
- Pour le CLS : réserver systématiquement la largeur et la hauteur des images et des vidéos, et éviter d’injecter du contenu au-dessus de ce que l’utilisateur regarde déjà.
- Après chaque correctif, remesurer avec Lighthouse en conditions réseau ralenties, puis attendre le cycle de 28 jours de Search Console pour confirmer l’effet sur les données de terrain.
Une refonte ou une migration de site est le moment le plus risqué pour ces indicateurs, car un nouveau thème ou un nouveau CMS peut dégrader le CLS sans que personne ne le remarque avant la publication. Notre retour d’expérience sur la migration de site sans perte de SEO détaille comment sécuriser ce point précis.
Priorité de correction avec des ressources limitées
Sans budget dev illimité, l’ordre de priorité compte plus que l’exhaustivité. Traiter d’abord l’indicateur classé « médiocre » sur le plus grand volume de pages dans Search Console, puisque c’est là que se joue l’essentiel du trafic. Ensuite seulement affiner les pages déjà « à améliorer ».
Sur la majorité des sites B2B dont nous auditons les Core Web Vitals, l’image hero surdimensionnée et les scripts tiers non différés expliquent à eux seuls plus de la moitié des échecs.
Note terrain Lead4you
Parmi les trois Core Web Vitals, le CLS est presque toujours le signal le plus négligé sur les sites que nous auditons, alors qu’il est souvent le moins coûteux à corriger. La cause récurrente : des bannières de consentement cookies ou des widgets de chat injectés en JavaScript après le rendu initial, qui décalent tout le contenu visible d’un coup. Réserver leur espace dans le CSS dès le départ, plutôt que de les laisser s’insérer dynamiquement, corrige souvent 70 à 80 % du score CLS d’un site sans toucher au reste du code.
Checklist rapide Core Web Vitals
- Consulter le rapport « Signaux Web essentiels » de Search Console avant tout diagnostic ponctuel.
- Identifier le groupe d’URL et l’indicateur qui concentrent le plus d’échecs.
- Compresser et précharger l’image ou l’élément principal responsable du LCP.
- Différer les scripts tiers non essentiels pour réduire l’INP.
- Réserver la largeur et la hauteur de chaque image, vidéo et bannière dynamique.
- Remesurer avec Lighthouse après chaque correctif, puis confirmer sur 28 jours de données réelles.
Demander un diagnostic technique de vos Core Web Vitals
À lire ensuite
Sources et repères utiles
FAQ
Qu’est-ce que les Core Web Vitals ?
Ce sont trois métriques Google — LCP, INP et CLS — qui mesurent la vitesse de chargement, la réactivité aux interactions et la stabilité visuelle d’une page, à partir de données collectées sur de vrais visiteurs plutôt qu’en laboratoire.
Les Core Web Vitals influencent-ils vraiment le classement Google ?
Oui, ils font partie des signaux d’expérience de page utilisés dans le classement, mais ils pèsent moins que la pertinence du contenu. Leur effet le plus visible reste sur le taux de conversion et le taux de rebond, pas uniquement sur la position.
Quelle différence entre le LCP et l’INP ?
Le LCP mesure le temps d’affichage du plus grand élément visible au chargement. L’INP mesure le délai entre une interaction, comme un clic, et la réponse visuelle de la page. Ce sont deux moments différents du parcours utilisateur.
Pourquoi mon score change entre PageSpeed Insights et Search Console ?
PageSpeed Insights teste une page isolée en laboratoire, dans des conditions contrôlées. Search Console agrège les données réelles de tous vos visiteurs sur 28 jours. Les deux se complètent mais ne mesurent pas exactement la même chose.
Combien de temps pour voir l’effet d’une correction ?
Un test Lighthouse confirme l’amélioration technique immédiatement. Le statut officiel dans Search Console, basé sur des données de terrain, met en général jusqu’à 28 jours à se mettre à jour complètement.
Faut-il tout corriger d’un coup ?
Non. Mieux vaut traiter en priorité l’indicateur le plus dégradé sur le plus grand volume de pages, mesurer l’effet, puis passer au suivant. Une correction isolée et vérifiée vaut mieux qu’une refonte globale non mesurée.