Un client m'appelle lundi matin, un peu paniqué. Trois semaines plus tôt, on avait refait tout son site e-commerce. Design nickel, contenus propres. Et là, son référencement naturel s'effondre. Pas de pénalité, pas de message dans la Search Console. Juste une chute lente, semaine après semaine. Sa question : « C'est vraiment ces Core Web Vitals qui me plombent ? »
Franchement, j'aurais aimé lui répondre non. Parce que la vérité est plus ennuyeuse : les Core Web Vitals ne sont pas le levier magique qu'on vous vend partout. Mais quand ils partent en vrille, ils ajoutent un handicap sur un site qui n'avait déjà pas besoin de ça. Alors voici comment je travaille, ce que j'ai testé, et surtout ce qui n'a servi à rien.
Points clés à retenir
- Les Core Web Vitals, ce sont trois signaux mesurés sur vos vraies visites, pas dans un laboratoire.
- Seuils à viser : LCP sous 2,5 s, INP sous 200 ms, CLS sous 0,1.
- L'INP a remplacé le FID : ce n'est plus la réactivité au premier clic qui compte, mais celle de toute la page.
- Un écart entre PageSpeed Insights et vos données de terrain est normal. Le terrain gagne toujours.
- Optimiser le LCP fait souvent gagner de la conversion bien avant de faire bouger le classement.
- Mesurer mal coûte cher : on croit optimiser alors qu'on déplace juste le problème.
Core Web Vitals : la définition qu'on vous donne est incomplète
Vous connaissez la version courte. Trois métriques, des seuils, un joli feu vert dans la Search Console. Ce qu'on vous dit moins : ces trois chiffres sont calculés à partir des données réelles de navigation collectées auprès des utilisateurs de Chrome. Concrètement, quelqu'un qui visite votre site depuis une connexion mobile médiocre influence votre score. Pas votre serveur de test posé à côté de la machine de développement.
C'est là que la plupart des équipes se trompent. Elles optimisent pour Lighthouse, pas pour leurs visiteurs.
Les trois métriques, sans jargon
- LCP : le temps avant que le plus gros élément visible s'affiche. Une image de bannière, un titre, une vidéo de fond. Si c'est lent, l'utilisateur a l'impression que rien ne se passe.
- INP : le délai entre une interaction et la réaction de la page. Clic sur un menu, saisie dans un formulaire. Un INP mauvais, c'est un site qui « ne répond pas ».
- CLS : les décalages de mise en page. Vous visez un bouton, une pub se charge, vous cliquez à côté. Le CLS mesure cette agacement invisible.
Et un point qui date : l'INP est devenu métrique officielle en mars 2024, en remplacement du FID. Beaucoup de contenus en ligne ne l'ont pas mis à jour. Si vous lisez encore qu'il faut surveiller le FID, fermez l'onglet.
Mesurer avant d'optimiser : le piège des chiffres de laboratoire
Un test PageSpeed Insights me renvoie un 38 sur mobile. Le même jour, les données de terrain affichent un LCP à 2,1 s, donc dans le vert. Qui croire ?
La réponse est simple, et je le répète à chaque audit : le terrain gagne, toujours. Les données de laboratoire simulent un appareil bridé et une connexion lente. Utiles pour reproduire un problème. Pas pour juger votre état réel.
Pourquoi l'écart entre laboratoire et terrain est normal
Sur un projet de site de presse, j'ai passé deux semaines à optimiser le LCP en laboratoire. Résultat : magnifique 1,8 s dans Lighthouse. Réaction sur le terrain : rien. Absolument rien.
Le problème ? Le LCP réel était causé par une image hébergée chez un tiers, chargée en parallèle d'un script publicitaire. Rien de tout ça n'apparaissait dans mon test local. J'ai perdu quatorze jours sur un faux coupable.
| Source | Ce qu'elle mesure | Quand s'en servir |
|---|---|---|
| Terrain (données réelles) | Visiteurs réels, tous appareils | Décider s'il faut agir |
| Laboratoire (audit technique) | Appareil bridé, réseau simulé | Trouver la cause |
| PageSpeed Insights | Les deux, côte à côte | Comparer les écarts |
Si je ne devais garder qu'un réflexe : ouvrir les données de terrain d'abord, et ne sortir l'audit technique que pour comprendre un écart. Dans l'autre sens, vous perdez du temps sur des problèmes que personne ne vit.
Test Core Web Vitals : comment le faire sans se raconter d'histoires
Il n'existe pas un seul test. Il en existe deux, et ils ne racontent pas la même chose.
- Ouvrez les données de terrain pour vos pages principales. C'est votre photo de départ.
- Repérez les pages hors seuil. Souvent, ce ne sont pas celles qu'on imagine.
- Pour chaque page fautive, lancez un audit technique et cherchez la cause, pas le score.
- Notez le point de départ. Sans cette note, vous ne saurez jamais si votre correction a servi à quelque chose.
Un détail que j'ai mis du temps à comprendre : sur la plupart des sites que j'audite, une poignée de modèles de pages concentre l'essentiel des mauvais chiffres. Une page catégorie, une fiche produit, un gabarit d'article. Corriger ces trois-là fait bouger l'ensemble. Optimiser les 400 pages une par une ? Perte de temps pure.
Évaluation Core Web Vitals en échec : ce que ça veut vraiment dire
Un « échec » dans la Search Console ne veut pas dire que Google vous sanctionne. Il veut dire qu'un pourcentage de vos visites réelles dépasse les seuils. Nuance importante, parce qu'un site peut être en échec sur le papier et parfaitement fonctionner pour ses utilisateurs.
Ce qui doit vous alerter, ce n'est pas le statut. C'est la tendance.
Les causes que je rencontre le plus souvent
- Une image de bannière servie en pleine résolution sur mobile.
- Des scripts tiers empilés sans contrôle : publicité, chat, analytics.
- Des polices chargées trop tard, qui font « sauter » le texte.
- Un hébergement correct mais une base de données lente sur les pages dynamiques.
- Des animations qui bloquent le fil principal.
Un client avait un INP catastrophique sur mobile uniquement. Cause : un widget de chat tiers qui reprenait la main à chaque interaction. Sur ordinateur, invisible. Sur un téléphone d'entrée de gamme, la page se figeait. On a déplacé le chargement du widget après interaction. INP divisé par trois. Aucune ligne de notre propre code touchée.
Avant de vous lancer
- Ne corrigez jamais un problème que le terrain ne montre pas.
- Visez les gabarits, pas les pages isolées.
- Les scripts tiers sont vos pires ennemis. Traitez-les en premier.
- Notez chaque point de départ. Sinon, aucune correction n'est vérifiable.
Ce qui reste, au bout du compte, c'est une question de priorité. Les Core Web Vitals ne feront jamais grimper un site sans contenu ni intention de recherche. Ils n'écrasent pas non plus un concurrent mieux positionné. Ce qu'ils font, c'est retirer un caillou de la chaussure d'un visiteur qui hésitait déjà à rester. Et ça, franchement, ça vaut le détour. Pas parce que Google l'a décrété. Parce que la personne en face de l'écran, elle, le ressent immédiatement.
