Trois lettres, trois questions simples
Les Core Web Vitals sont trois indicateurs que Google utilise pour juger l'expérience réelle d'une page, au-delà du simple « est-ce que ça marche ». Ils répondent chacun à une question qu'un visiteur se pose sans le formuler :
- LCP (Largest Contentful Paint) : combien de temps avant que je voie le contenu principal de la page ?
- INP (Interaction to Next Paint) : quand je clique ou je tape, est-ce que ça répond tout de suite ?
- CLS (Cumulative Layout Shift) : est-ce que la page bouge sous mes doigts pendant que je la lis ?
Aucun des trois ne mesure un ressenti vague. Les trois sont chiffrés, mesurables gratuitement, et Google publie les seuils exacts qui séparent une page « bonne », une page « à améliorer » et une page « mauvaise ».
| Indicateur | Bon | À améliorer | Mauvais |
|---|---|---|---|
| LCP | ≤ 2,5 s | 2,5 à 4 s | > 4 s |
| INP | ≤ 200 ms | 200 à 500 ms | > 500 ms |
| CLS | ≤ 0,1 | 0,1 à 0,25 | > 0,25 |
Ces trois métriques font officiellement partie des facteurs de classement de Google depuis 2021. Elles ne décident pas seules de votre position, mais à qualité de contenu égale, la page la plus rapide et la plus stable l'emporte presque toujours.
Pourquoi ça compte autant que le référencement
Le lien avec Google retient l'attention, mais l'impact commercial direct est plus important encore. Un visiteur qui attend plus de quatre secondes avant de voir votre page a, dans une large mesure, déjà quitté l'onglet avant que le contenu s'affiche. Celui qui tape son numéro de téléphone dans un formulaire qui met une demi-seconde à réagir à chaque frappe abandonne avant la fin. Celui qui clique sur un bouton qui se décale au moment du clic — parce qu'une bannière de cookies vient de s'afficher au-dessus — clique souvent sur la mauvaise chose, et ne revient pas.
Les Core Web Vitals ne sont donc pas un sujet pour développeurs : c'est un sujet de conversion, qui se traduit directement en formulaires envoyés et en appels reçus.
Comment mesurer ses Core Web Vitals gratuitement
Il existe deux familles d'outils, et la distinction compte.
Les données de terrain (ce que vos vrais visiteurs vivent)
- PageSpeed Insights (pagespeed.web.dev) : collez votre URL, vous obtenez à la fois les données réelles des visiteurs (quand le trafic est suffisant) et un test en conditions contrôlées.
- Search Console, rapport « Core Web Vitals » : montre l'évolution dans le temps, groupée par type de page, directement sur votre propre site.
- CrUX (Chrome User Experience Report) : la base de données publique derrière les deux outils précédents, consultable aussi via l'extension Chrome « Web Vitals ».
Les données de laboratoire (un test simulé, utile pour diagnostiquer)
- Lighthouse, intégré à Chrome DevTools (onglet « Lighthouse », bouton « Analyze page load »).
- PageSpeed Insights, qui combine les deux : terrain en haut, laboratoire en bas.
La règle à retenir : les données de terrain disent la vérité sur ce que vivent vos visiteurs ; les données de laboratoire servent à comprendre pourquoi et à vérifier qu'une correction fonctionne avant de la publier. Testez toujours sur mobile en priorité, et si possible en simulant une connexion 4G plutôt que le Wi-Fi du bureau : c'est l'expérience réelle de la majorité de vos visiteurs.
Les causes réelles de lenteur, classées par gain attendu
Voici, par ordre d'impact généralement observé, les causes les plus fréquentes et ce qu'elles coûtent à chaque métrique.
| # | Cause | Métrique touchée | Gain attendu |
|---|---|---|---|
| 1 | Images non compressées ou mal dimensionnées | LCP | Souvent le plus gros gain, parfois 1 à 2 secondes |
| 2 | Polices web qui bloquent l'affichage du texte | LCP, CLS | Gain modéré à élevé, correction rapide |
| 3 | JavaScript tiers (chat, bannières, widgets) exécuté avant l'interaction | INP | Gain élevé sur mobile en particulier |
| 4 | Hébergement ou serveur lent à répondre | LCP | Gain élevé si le temps de réponse serveur dépasse 600 ms |
| 5 | Éléments publicitaires ou bannières sans dimension réservée | CLS | Correction quasi gratuite une fois identifiée |
| 6 | Absence de mise en cache ou de CDN | LCP | Gain surtout sensible pour les visiteurs éloignés du serveur |
| 7 | Animations ou carrousels lourds en page d'accueil | INP, CLS | Gain variable, souvent sous-estimé |
La cause numéro un, dans l'immense majorité des sites de PME que nous auditons, reste l'image non optimisée : une photo de 4 Mo sortie directement d'un téléphone et uploadée sans compression ni redimensionnement sur la page d'accueil. C'est aussi la correction la plus rapide à apporter, et souvent celle qui produit le gain le plus visible.
Corriger chaque métrique, concrètement
Faire baisser le LCP
- Compresser et redimensionner les images à la taille réellement affichée, pas à la taille d'origine
- Utiliser des formats modernes (WebP, AVIF) plutôt que JPEG ou PNG non optimisés
- Charger l'image principale en priorité (
fetchpriority="high") et différer le reste - Réduire le temps de réponse du serveur : un hébergement mutualisé saturé est une cause fréquente et sous-estimée
- Éviter de charger des polices ou scripts bloquants avant le contenu visible
Faire baisser l'INP
- Limiter le nombre de scripts tiers chargés au démarrage (chat en direct, pixels, widgets d'avis)
- Différer leur exécution jusqu'après l'interaction de l'utilisateur plutôt qu'au chargement de la page
- Découper les tâches JavaScript longues plutôt que d'exécuter un bloc unique qui gèle l'interface
- Tester en priorité sur un téléphone d'entrée de gamme : l'INP s'y dégrade bien plus vite que sur un ordinateur de bureau
Faire baisser le CLS
- Réserver systématiquement un espace (attribut
width/heightouaspect-ratio) pour chaque image et vidéo avant son chargement - Réserver l'espace des bannières de cookies et des publicités avant qu'elles ne s'affichent
- Éviter d'insérer du contenu au-dessus de ce que l'utilisateur est en train de lire
- Précharger les polices pour éviter le changement de mise en page au moment où elles s'affichent
Les pièges qui faussent le diagnostic
- Tester uniquement sur son propre ordinateur, en fibre. Vos visiteurs sont majoritairement sur mobile, en 4G. L'écart peut être considérable.
- Se fier à un seul test de laboratoire. Un résultat Lighthouse peut varier de 20 % entre deux exécutions sur la même page ; privilégiez la tendance sur plusieurs jours via Search Console.
- Corriger une page et ignorer les autres. Les Core Web Vitals sont mesurés gabarit par gabarit : une page d'accueil excellente n'empêche pas une page produit catastrophique.
- Confondre vitesse perçue et score affiché. Un score Lighthouse de 95 ne garantit rien si les données de terrain réelles, dans Search Console, racontent une autre histoire — c'est toujours elles qui comptent pour le classement.
Ce qu'on observe en pratique
Quand nous auditons un site avant une refonte, les trois métriques sont rarement toutes mauvaises en même temps : c'est en général une seule cause structurelle qui tire tout vers le bas, le plus souvent les images ou un hébergement sous-dimensionné. Nos forfaits de maintenance à partir de 150 € par mois incluent justement un suivi régulier de ces trois indicateurs, précisément parce qu'un site qui passait au vert à la mise en ligne peut redevenir rouge six mois plus tard, à mesure que les images et les plugins s'accumulent sans surveillance.
Si vos Core Web Vitals sont dans le rouge depuis longtemps et que la cause est structurelle (hébergement, CMS, architecture du thème), une optimisation ponctuelle ne suffira pas : c'est un signal qui mérite d'être mis en regard des sept signaux qui indiquent qu'une refonte est nécessaire.
En résumé
- Le LCP mesure le temps d'affichage du contenu principal (bon sous 2,5 s), l'INP la réactivité aux interactions (bon sous 200 ms), le CLS la stabilité visuelle (bon sous 0,1)
- Mesurez gratuitement avec PageSpeed Insights et le rapport Core Web Vitals de Search Console, en priorité sur mobile
- La cause la plus fréquente et la plus rentable à corriger reste l'image non optimisée
- Corrigez gabarit par gabarit, pas seulement la page d'accueil
- Surveillez dans le temps : un site optimisé une fois peut se dégrader en quelques mois sans suivi
Vous voulez savoir où se situe votre site aujourd'hui, et ce qu'il faudrait corriger en priorité ? Décrivez votre projet en deux minutes, nous vous répondons avec un diagnostic argumenté en moins de 24 heures : démarrer mon projet.