Core Web Vitals : le guide sans jargon pour dirigeants

Pourquoi Google mesure-t-il ça ?

Google veut envoyer ses utilisateurs vers des pages agréables à utiliser. Depuis 2021, il intègre donc dans son classement trois mesures d'expérience baptisées Core Web Vitals. Ce n'est pas le signal le plus puissant du SEO, mais c'est un signal, et surtout c'est un facteur de conversion : une page qui met 6 secondes à s'afficher perd une partie de ses visiteurs avant même d'avoir montré quoi que ce soit.

Les trois métriques, traduites

• LCP (Largest Contentful Paint), le chargement. Temps d'affichage du plus gros élément visible, en général votre image ou titre principal. C'est la sensation « le site est là ». Cible : 2,5 secondes ou moins.
• INP (Interaction to Next Paint), la réactivité. Délai entre une action (clic, saisie) et la réaction visible de la page. C'est la sensation « ça répond ». Cible : 200 ms ou moins.
• CLS (Cumulative Layout Shift), la stabilité. Mesure les décalages de mise en page pendant le chargement, ce moment où le bouton bouge juste quand vous alliez cliquer dessus. Cible : 0,1 ou moins.

Le barème Lighthouse qui les accompagne est simple : un score de performance de 90 à 100 est bon, de 50 à 89 à surveiller, en dessous de 50 à corriger.

Données terrain ou laboratoire ?

Deux façons de mesurer, et elles ne racontent pas la même chose. Les données terrain (CrUX) sont collectées par Google sur vos vrais visiteurs Chrome des 28 derniers jours : c'est la vérité, mais il faut du trafic pour en avoir. Les données laboratoire (Lighthouse) sont une simulation dans des conditions standardisées : disponibles pour tout site, mais théoriques. Les petits sites n'ont souvent que le laboratoire ; c'est déjà un excellent indicateur de tendance. Notre rapport indique toujours laquelle des deux sources il affiche.

Faut-il viser 100/100 ?

Non, et courir après le 100 est l'un des meilleurs moyens de gaspiller un budget. Deux raisons.

D'abord, ce que Google évalue pour le classement, ce sont les seuils des trois métriques, pas le score Lighthouse. Un site dont le LCP est à 2,3 s, l'INP à 150 ms et le CLS à 0,05 est au vert sur toute la ligne, que son score affiche 92 ou 78. Passer ce même site de 92 à 100 n'apporte rien au référencement.

Ensuite, le coût n'est pas linéaire. Amener une page de 40 à 75 se fait en général en une demi-journée, avec deux ou trois gestes simples : les images, les scripts inutiles, la compression. Aller de 90 à 100 demande souvent de découper des feuilles de style, de retirer des fonctionnalités et de renoncer à des outils que l'entreprise utilise vraiment. Le rapport entre l'effort et le gain s'inverse quelque part vers 85.

La bonne question n'est donc pas « quel est mon score » mais « suis-je au vert sur les trois seuils, en mobile ». Si oui, le sujet est clos, passez au contenu.

Les 3 causes qui reviennent partout

Après des dizaines d'audits de sites de TPE-PME, trois causes expliquent l'écrasante majorité des mauvais scores :

1. Les images trop lourdes. Une photo sortie d'un appareil moderne pèse 4 à 8 Mo. Posée telle quelle en image de fond, elle ruine le LCP à elle seule. Correctif : redimensionner à la taille d'affichage réelle et convertir en WebP ou AVIF. Une image de héros doit peser moins de 200 Ko.
2. Les scripts tiers. Widget de chat, tracking, polices externes, vidéos intégrées : chaque script tiers bloque potentiellement le fil principal. Correctif : supprimer ceux qui ne servent plus (il y en a presque toujours), charger les autres en différé.
3. L'hébergement sous-dimensionné. Si le serveur met 1,5 seconde à répondre avant même d'envoyer la page, aucune optimisation ne rattrapera ce retard. Correctif : activer la compression et le cache serveur, ou changer d'offre. Ça se mesure au TTFB (time to first byte, viser moins de 600 ms).

Comment corriger le CLS sans tout casser ?

Le CLS est la métrique la plus mal diagnostiquée des trois, parce que le coupable est rarement celui qu'on accuse. Un élément ne peut décaler la page que s'il entre dans le flux après le premier affichage. Un bloc positionné en absolu, ou une grille à colonnes fixes, ne décale rien, même s'il s'anime beaucoup et attire l'œil.

Les quatre causes réelles, par fréquence :

• Une image sans width ni height. Le navigateur ne sait pas quelle place lui réserver, il affiche le texte, puis pousse tout vers le bas quand l'image arrive. C'est la cause numéro un, et la plus facile à corriger.
• Un élément masqué qui réapparaît. Attention au piège : masquer avec l'attribut hidden ou display:none sort l'élément du flux. Quand il revient, ses voisins se redisposent. Si l'emplacement doit rester réservé, utilisez visibility:hidden, qui garde la place. Nous nous sommes fait prendre sur notre propre page d'accueil par un compteur chargé après une requête réseau.
• Une bannière ou un bandeau inséré en haut de page après coup : il pousse toute la page vers le bas d'un coup.
• Une police personnalisée dont les lettres n'ont pas la même largeur que la police de secours : le texte se remet en page quand la vraie police arrive.

Le réflexe utile avant de corriger : ouvrez l'onglet Performance de votre navigateur et regardez quel élément bouge. Corriger au jugé fait perdre des journées, comme l'a vécu ce site.

En combien de temps Google en tient-il compte ?

Voilà ce que personne ne dit et qui provoque le plus de découragement : les données terrain de Google sont une moyenne glissante sur 28 jours. Le jour où vous corrigez vos images, la mesure ne bouge presque pas, parce qu'elle contient encore 27 jours de visites sur l'ancienne version.

Comptez donc environ un mois pour voir la correction pleinement reflétée dans la Search Console, et n'en concluez pas au bout d'une semaine que votre travail n'a servi à rien. Le laboratoire, lui, réagit immédiatement : mesurez-y l'effet de votre correction le jour même, puis attendez le terrain pour la confirmation.

Comment mesurer chez vous ?

Notre audit gratuit interroge l'API PageSpeed Insights de Google et affiche vos trois métriques avec leur source (terrain ou laboratoire), intégrées au score de la catégorie Performance. Vous pouvez aussi utiliser PageSpeed Insights directement : même donnée, sans le reste de l'audit. Mesurez la version mobile d'abord : c'est elle que Google regarde, et c'est presque toujours la moins bonne des deux.