Sur cette page · 9 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.
Les trois métriques que Google mesure sur chaque page de votre site, ce qu’elles signifient concrètement pour vos visiteurs, et les actions à entreprendre si vos scores sont mauvais. Zéro ligne de code.
Trois notes, pas trente
Google mesure des centaines de signaux pour classer votre site. Mais en 2024, il a réduit l’évaluation de l’expérience utilisateur à 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 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).
Un site WordPress moyen charge entre 300 et 450 KB de JavaScript. Chaque script bloque le navigateur pendant qu’il s’exécute. Résultat : même si la page semble chargée, elle ne réagit pas aux clics. C’est exactement ce qu’INP mesure — et c’est la métrique la plus souvent échouée en 2026.
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.
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 |
|---|---|---|
| Taux d’abandon | -24% quand les 3 seuils sont atteints | Google (2024) |
| 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.
Un site qui passe les trois seuils Core Web Vitals perd 24% de visiteurs en moins qu’un site qui les échoue. Ce n’est pas un avantage SEO — c’est un avantage commercial.
Données Google, confirmées par les études de cas web.dev.Comment vérifier vos scores
Vous n’avez pas besoin d’ouvrir un terminal. Trois outils gratuits suffisent :
Ouvrez le rapport Core Web Vitals. Il montre vos pages groupées par bon / à améliorer / mauvais, sur données réelles.
Testez une URL spécifique. Le score du haut est un test lab. La section "Données terrain" montre les vrais utilisateurs.
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.
Allez sur pagespeed.web.dev, collez l’URL de votre page d’accueil, et regardez uniquement la section “Évaluation des Core Web Vitals” en haut. Trois indicateurs verts = tout va bien. Un indicateur orange ou rouge = il faut agir.
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.
Ce qu’il faut faire si vos scores sont mauvais
Votre site est dans le rouge ? Voici les actions par ordre d’impact, sans toucher au code :
Pour améliorer le LCP :
- Compressez vos images (format WebP, pas de fichiers de plus de 200 KB)
- Réduisez le nombre de plugins WordPress actifs
- Passez sur un hébergement plus rapide (ou un CDN comme Cloudflare)
Pour améliorer l’INP :
- Désactivez les plugins JavaScript non essentiels (sliders, popups, chatbots)
- Différez le chargement des scripts tiers (analytics, pixels publicitaires)
- Si le problème persiste malgré ces mesures, la cause est structurelle — liée à l’architecture serveur + client de WordPress, pas à sa configuration
Pour améliorer le CLS :
- Ajoutez des dimensions (largeur × hauteur) à toutes vos images
- Réservez de l’espace pour les publicités et embeds
- Évitez les polices web qui chargent en retard (ou préchargez-les)
Si votre site WordPress est en dessous de 60 en Lighthouse Performance malgré l’optimisation des images et la réduction des plugins, le problème n’est plus dans la configuration. Il est dans l’architecture — PHP côté serveur, JavaScript côté client, base de données à chaque requête. Aucun plugin de cache ne corrige ça durablement.
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.
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.