Sur cette page · 11 sections
Votre développeur vous parle de LCP, de CLS, d’INP. Votre agence SEO vous dit que “les Core Web Vitals sont dans le rouge”. Google Search Console affiche des alertes orange. Et vous, vous voulez juste savoir si votre site va bien — et ce qu’il faut faire s’il ne va pas bien.
Ce guide est écrit pour vous. Pas pour les développeurs.
Lire le rapport Search Console#
Si vous êtes ici, Search Console vous a probablement envoyé une alerte. Le rapport Core Web Vitals classe vos pages en trois statuts : Bon, Amélioration nécessaire et Médiocre. Trois choses à savoir avant de toucher à quoi que ce soit, toutes tirées de l’aide officielle de Search Console.
Les pages sont regroupées. Google rassemble les URL qui offrent une expérience similaire, souvent des pages construites sur le même modèle. Un groupe de 300 pages en rouge, c’est souvent un seul modèle de page à corriger, pas 300 problèmes.
Les données sont réelles, et elles couvrent 28 jours. Le rapport s’appuie sur les mesures des vrais visiteurs sous Chrome (le rapport CrUX), cumulées sur les 28 derniers jours. C’est ce que Google utilise, et c’est pourquoi une correction met environ un mois à apparaître.
Une page absente n’est pas une page saine. Une URL sans assez de visites n’a pas de données propres : elle est rangée avec le reste du site, ou n’apparaît pas. Pour elle, seul un test comme PageSpeed Insights vous renseigne.
Vous n’avez pas besoin d’ouvrir un terminal. Trois outils gratuits suffisent :
- Search Console
Ouvrez le rapport Core Web Vitals. Il montre vos pages groupées par bon / à améliorer / mauvais, sur données réelles.
- PageSpeed Insights
Testez une URL précise. La section du haut, l'évaluation des Core Web Vitals, montre vos vrais visiteurs. La note sur 100, plus bas, vient d'un test de laboratoire.
- Lighthouse (Chrome)
F12 → onglet Lighthouse → Generate report. Résultat immédiat, mais c'est un test labo — pas les données réelles.
La différence entre données labo et données terrain est importante. Un test Lighthouse simule un chargement. Les données terrain (dans Search Console et PageSpeed Insights) mesurent ce que vos vrais visiteurs vivent. Google utilise les données terrain pour le classement — pas le score Lighthouse.
Si votre Lighthouse est à 95 mais vos données terrain sont “mauvaises”, c’est les données terrain qui comptent.
Trois notes, pas trente#
Google mesure des centaines de signaux pour classer votre site. Mais pour l’expérience utilisateur, il s’en tient depuis 2020 à trois métriques précises. Trois. C’est gérable.
Ces trois métriques s’appellent les Core Web Vitals. Chacune mesure un aspect différent de ce que ressent une personne qui visite votre site :
- LCP — Est-ce que la page charge vite ?
- INP — Est-ce que la page réagit quand on clique ?
- CLS — Est-ce que la page bouge pendant le chargement ?
Chaque métrique a un seuil. En dessous, Google considère que l’expérience est “bonne”. Au-dessus, elle est “à améliorer” ou “mauvaise”. Il n’y a pas de zone grise.
LCP : le temps avant de voir quelque chose d’utile#
Largest Contentful Paint. En français : le temps que met l’élément le plus gros de votre page à apparaître. Souvent, c’est l’image principale, la bannière, ou le premier gros bloc de texte.
| Seuil | Score |
|---|---|
| Bon | Moins de 2,5 secondes |
| À améliorer | Entre 2,5 et 4 secondes |
| Mauvais | Plus de 4 secondes |
Ce que ça veut dire pour vous : si votre page met plus de 2,5 secondes à afficher quelque chose, vos visiteurs voient un écran blanc. Et 32% d’entre eux partent si le chargement dépasse 3 secondes.
Les causes les plus fréquentes : images non optimisées (trop lourdes, pas au bon format), serveur lent, trop de CSS et JavaScript à charger avant d’afficher quoi que ce soit.
INP : le temps avant que la page réagisse#
Interaction to Next Paint. C’est la métrique la plus récente — elle a remplacé FID (First Input Delay) le 12 mars 2024. La différence : FID ne mesurait que le premier clic. INP mesure toutes les interactions.
Vous cliquez sur un bouton “Ajouter au panier”. INP mesure le temps entre votre clic et le moment où quelque chose change à l’écran.
| Seuil | Score |
|---|---|
| Bon | Moins de 200 millisecondes |
| À améliorer | Entre 200 et 500 ms |
| Mauvais | Plus de 500 ms |
Ce que ça veut dire pour vous : si votre site met plus de 200 ms à réagir à un clic, vos visiteurs ressentent un “lag”. Sur mobile, c’est encore plus flagrant — et, selon le Web Almanac 2025 d’HTTP Archive, 23% des sites mobiles échouent sur ce seuil. Quand on combine les trois métriques, seuls 48% des sites mobiles passent l’ensemble des Core Web Vitals.
Les causes les plus fréquentes : trop de JavaScript qui bloque le navigateur, plugins WordPress mal codés, scripts tiers (chatbots, analytics, widgets sociaux).
CLS : les éléments qui bougent tout seuls#
Cumulative Layout Shift. Vous lisez un texte, et soudain le contenu descend parce qu’une publicité s’est insérée au-dessus. Ou vous allez cliquer sur un lien, et une image se charge juste avant — vous cliquez sur le mauvais endroit.
CLS mesure la quantité de mouvement involontaire sur votre page.
| Seuil | Score |
|---|---|
| Bon | Moins de 0,1 |
| À améliorer | Entre 0,1 et 0,25 |
| Mauvais | Plus de 0,25 |
Ce que ça veut dire pour vous : un score CLS de 0 signifie que rien ne bouge sur votre page pendant le chargement. Un score au-dessus de 0,1 signifie que quelque chose se déplace de façon visible et gênante.
Les causes les plus fréquentes : images sans dimensions déclarées (largeur × hauteur), polices web qui remplacent les polices système en retard, publicités et embeds qui s’insèrent dynamiquement.
Ce que vous pouvez corriger seul, et ce qui demande un développeur#
Repérez d’abord la métrique en cause dans le rapport, puis lisez la ligne qui la concerne. La colonne du milieu se fait depuis votre back-office, la dernière demande d’ouvrir le code.
| Métrique en rouge | Ce que vous pouvez faire seul | Ce qui demande un développeur |
|---|---|---|
| LCP, la page charge lentement | Compresser l’image principale (WebP, moins de 200 Ko), supprimer le diaporama d’accueil, activer un cache et un CDN comme Cloudflare | Prioriser le chargement de l’image principale, alléger le CSS qui bloque l’affichage, changer d’hébergement |
| INP, la page réagit mal | Désactiver les plugins JavaScript non essentiels (diaporamas, pop-ups, chats), retirer les scripts tiers inutiles | Différer ou découper le JavaScript restant, remplacer un thème ou un constructeur de pages trop lourd |
| CLS, la page bouge | Renseigner la largeur et la hauteur des images, réserver la place des publicités et des vidéos intégrées | Précharger les polices web, réserver dans le gabarit la place des bannières (cookies, promotions) |
Si votre site tourne sous WordPress, les causes de sa lenteur sont détaillées une par une, avec ce qu’on peut faire sans migrer.
Après la correction : pourquoi c’est encore rouge#
Vous avez corrigé, testé sur PageSpeed Insights, tout est vert. Et Search Console affiche toujours Médiocre. C’est normal : le rapport cumule 28 jours de visites réelles, donc les mesures d’avant votre correction pèsent encore pendant plusieurs semaines.
Pour suivre la résolution, ouvrez le problème dans le rapport et cliquez sur Démarrer le suivi. Google ouvre une session de surveillance de 28 jours : si le problème ne réapparaît sur aucune URL pendant cette période, il est considéré comme résolu. Comptez donc un mois entre la correction et le passage au vert, et ne refaites pas tout entre-temps.
Pourquoi Google s’en préoccupe (et vous aussi)#
Google ne vous punit pas pour le plaisir. Il veut que ses utilisateurs trouvent des résultats qui se chargent vite, réagissent aux clics, et ne sautent pas dans tous les sens. Si votre site fait tout ça correctement, Google le favorise. Si deux sites ont un contenu de qualité équivalente, celui avec de meilleurs Core Web Vitals passera devant.
Les chiffres sont concrets :
| Indicateur | Impact mesuré | Source |
|---|---|---|
| Ventes (Vodafone) | +8% après 31% d’amélioration du LCP | web.dev |
| Taux de rebond | +32% quand le chargement dépasse 3 secondes | Google / Akamai |
| Taux de conversion | -40 à -50% quand le LCP passe de 2s à 4-5s | Blue Triangle |
| Abandon de chargement | -76% après optimisation LCP (Agrofy) | web.dev |
| Taux de rebond global | -43% après optimisation LCP + CLS (Economic Times) | web.dev |
En résumé : de mauvais Core Web Vitals ne font pas que baisser votre position Google. Ils font fuir les visiteurs qui arrivent quand même.
Vodafone a amélioré son LCP de 31% et vendu 8% de plus. Ce n’est pas un avantage SEO — c’est un avantage commercial.
Étude de cas Vodafone, web.dev.
Pourquoi les sites Astro passent les trois seuils par défaut#
Ce n’est pas de la magie. C’est de l’architecture.
Un site Astro génère du HTML statique au moment de la construction. Quand un visiteur arrive, le serveur envoie une page HTML prête — pas un framework JavaScript qui doit reconstruire la page dans le navigateur.
Concrètement :
- LCP → La page est du HTML pur. Pas de JavaScript à exécuter avant d’afficher le contenu. Sur les sites que nous livrons, le LCP est sous 1,2 seconde en médiane.
- INP → Zéro JavaScript envoyé par défaut. Pas de script qui bloque le navigateur. Sur les pages sans interactivité, INP mesuré à 0 ms.
- CLS → Astro optimise les images au build (dimensions déclarées, formats WebP, responsive). Rien ne bouge au chargement. CLS mesuré à 0 sur nos déploiements.
Les sites Astro que nous livrons chez Astro4B atteignent un score Lighthouse Performance de 95 à 100. Ce n’est pas un objectif — c’est une conséquence de l’architecture. Le comparatif complet avec WordPress détaille l’écart poste par poste.
Ce que les Core Web Vitals ne mesurent pas#
Gardons les pieds sur terre. Les Core Web Vitals ne mesurent pas :
- La qualité de votre contenu (qui reste le facteur de classement le plus important)
- La pertinence de vos mots-clés
- La qualité de vos backlinks
- L’intention de recherche
Un site avec un contenu médiocre et des Core Web Vitals parfaits ne se classera pas. Mais un site avec un excellent contenu et des Core Web Vitals mauvais laisse de l’argent sur la table — en SEO et en conversions.
Questions fréquentes#
Les Core Web Vitals sont-ils un facteur de classement ?
Oui, parmi les signaux d'expérience de page que Google prend en compte. Mais le contenu pèse plus lourd : selon la documentation de Google, de bons Core Web Vitals ne garantissent pas un bon classement. Leur effet se voit surtout entre des pages de qualité comparable.
Pourquoi PageSpeed est vert alors que Search Console dit Médiocre ?
La note sur 100 de PageSpeed Insights vient d'un test de laboratoire, sur une visite simulée. Search Console mesure vos vrais visiteurs sur 28 jours, avec leurs téléphones et leurs connexions : c'est cette mesure que Google utilise. Dans PageSpeed, c'est la section du haut, l'évaluation des Core Web Vitals, qui doit concorder avec Search Console.
Pourquoi certaines pages n’apparaissent pas dans le rapport ?
Parce qu'elles n'ont pas assez de visites pour avoir des données propres. Google les range alors avec l'ensemble du site, ou les laisse de côté. Pour ces pages, un test PageSpeed Insights est la seule mesure disponible.
J’ai corrigé : combien de temps avant de voir le vert ?
Environ un mois. Le rapport cumule 28 jours de visites réelles, et le suivi lancé avec « Démarrer le suivi » dure lui aussi 28 jours.
Mobile ou ordinateur : lequel regarder en premier ?
Le mobile. Search Console mesure les deux séparément, et le mobile est presque toujours le moins bon : téléphones moins puissants, connexions plus lentes. Un site vert sur mobile l'est en général aussi sur ordinateur.
Faut-il viser 100 sur PageSpeed ?
Non. L'objectif est que vos pages passent les trois seuils en données réelles. Une note de laboratoire au-dessus de 90 donne de la marge ; viser 100 demande souvent beaucoup de travail pour un gain que vos visiteurs ne verront pas.
Collez votre URL dans PageSpeed Insights — le diagnostic prend 30 secondes. Si vos Core Web Vitals sont dans le rouge et que l’optimisation a ses limites, composez votre projet dans le configurateur : vous verrez ce qu’un site à 95+ en Lighthouse coûterait, fonctionnalités identiques.