Optimiser les Core Web Vitals pour le référencement : le guide

Il y a une question qu'on me pose à chaque audit, presque mot pour mot : « J'ai 94 sur PageSpeed Insights, pourquoi Google ne me remonte pas ? » Et à chaque fois, la même réponse un peu contrariante : votre 94 ne veut pas dire grand-chose. Ce qui compte, ce sont les Core Web Vitals, trois mesures de terrain que Google intègre à son algorithme depuis juin 2021, et qui racontent une histoire très différente de celle du score vert affiché par l'outil.

Optimiser les Core Web Vitals pour le référencement, ce n'est donc pas courir après une note. C'est travailler trois signaux précis, avec des seuils précis, sur des données réelles. Et c'est là que la plupart des sites que j'ai vus se trompent de cible.

Ce que les Core Web Vitals font vraiment à votre référencement

Soyons clairs sur le poids réel. Google l'a répété : les Core Web Vitals sont un facteur mineur de classement, un départage entre pages de pertinence comparable. Une page lente mais qui répond exactement à l'intention de recherche battra une page rapide hors sujet. J'ai vu des sites à 4 secondes de LCP en première position. Ça existe.

Mais l'inverse est vrai aussi, et c'est là que ça devient intéressant. Sur un secteur concurrentiel où dix pages se valent en contenu, celui qui charge en 1,8 s passe devant. Pas parce que Google l'a décidé arbitrairement, mais parce que les utilisateurs cliquent, restent, et ne reviennent pas en arrière. Le comportement réel pèse plus lourd que la métrique elle-même.

Pourquoi les données de terrain comptent plus que le laboratoire

Le rapport CrUX (Chrome User Experience Report) alimente les métriques Core Web Vitals que Google utilise. Il agrège les mesures des vrais visiteurs sous Chrome, sur 28 jours glissants. C'est la référence. PageSpeed Insights, lui, simule un chargement dans des conditions fixées : un téléphone modeste, un réseau bridé. Utile pour diagnostiquer, trompeur pour juger.

Un exemple concret de terrain. Sur un site e-commerce de mobilier que j'ai audité, PageSpeed affichait un confortable 87 en mobile. Dans Search Console, l'onglet « Expérience de chargement » signalait 41 % d'URL en échec sur le LCP. L'écart venait des images produits servies en pleine résolution sur mobile, un problème que le laboratoire ne voyait pas parce qu'il testait une page type sans compte client. Le score vert masquait un problème réel chez la majorité des visiteurs.

Comprendre les trois métriques avant de toucher au code

Chaque métrique mesure une chose différente, et chacune a son propre mode de défaillance. Mélanger les trois, c'est s'assurer de ne rien réparer correctement.

LCP : le chargement perçu

Le Largest Contentful Paint mesure le temps avant que le plus gros élément visible ne s'affiche. En pratique, c'est presque toujours une image d'en-tête, une bannière ou un bloc de texte massif. Seuil : 2,5 secondes ou moins.

Ce que j'ai appris à mes dépens : le LCP n'est pas le temps de chargement de l'image en soi, mais le moment où elle devient visible. Une image servie en 400 ms peut produire un LCP de 3 secondes si elle attend que le navigateur ait découvert son URL dans le CSS ou le JavaScript. Le problème est plus souvent un problème de découverte que de poids.

INP : la réactivité, le vrai chantier

L'Interaction to Next Paint a remplacé le FID en mars 2024. Il mesure, sur l'ensemble des interactions d'une visite, le délai entre l'action de l'utilisateur (un clic, un tap) et le rafraîchissement visuel de la page. Seuil : 200 millisecondes au 75e centile.

C'est la métrique la plus difficile, et de loin la plus ignorée. Pourquoi ? Parce qu'elle ne se corrige pas en compressant une image. Elle dépend du fil principal du navigateur, saturé par les scripts. Un site léger en octets peut avoir un INP catastrophique à cause d'un seul script tiers d'analytics ou de chat qui bloque tout pendant 800 ms au moment du clic.

CLS : la stabilité visuelle

Le Cumulative Layout Shift quantifie à quel point la page bouge pendant le chargement. Un bandeau qui surgit et pousse le texte vers le bas, une image sans dimensions réservées : l'utilisateur clique à côté, s'énerve, repart. Seuil : 0,1 ou moins.

Bonne nouvelle : c'est presque toujours le plus simple à corriger. Mauvaise nouvelle : j'ai vu des sites accumuler des CLS de 0,4 avec des correctifs de deux lignes jamais appliqués, parfois pendant deux ans, simplement parce que personne ne lisait les données de terrain.

La méthode d'optimisation, métrique par métrique

Voici comment j'organise un chantier Core Web Vitals, dans l'ordre où je le ferais si je devais reprendre un site de zéro. L'ordre compte : le LCP d'abord parce que c'est le plus visible, le CLS ensuite parce que c'est rapide à régler, l'INP en dernier parce que c'est un travail de fond.

Métrique	Seuil bon	Levier principal	Effort typique
LCP	≤ 2,5 s	Précharger l'image LCP, priorité de récupération, CDN	Moyen, souvent 1 à 2 jours
INP	≤ 200 ms	Réduire le JavaScript, découper les tâches longues	Élevé, plusieurs semaines
CLS	≤ 0,1	Dimensions explicites, réservation d'espace	Faible, quelques heures

Attaquer le LCP

La première action est presque toujours la même : trouver l'élément qui porte le LCP, puis lui donner la priorité. Trois leviers concrets, dans l'ordre d'efficacité que j'ai constaté :

• Ajouter <link rel="preload"> sur l'image LCP, avec fetchpriority="high" sur la balise <img>. Effet immédiat sur la découverte.
• Servir cette image en format moderne (AVIF ou WebP) et à la bonne taille. Pas de photo de 3000 px pour un écran de 400.
• Éliminer ce qui bloque le rendu avant elle : un CSS critique en ligne, les scripts non critiques en defer.

Sur un site de presse que j'ai accompagné, la seule combinaison du preload et du fetchpriority sur l'image d'article a fait passer le LCP mobile de 3,6 s à 2,1 s. Aucun changement d'hébergement, aucune refonte. De la configuration, rien de plus.

Traiter le CLS en une après-midi

Trois causes écrasent toutes les autres : les images sans width et height, les polices web qui se chargent en décalant le texte, et les encarts publicitaires insérés sans espace réservé.

1. Dimensions explicites sur chaque image et chaque iframe, ou un ratio via CSS.
2. Précharger les polices, et prévoir une police de secours aux métriques proches.
3. Réserver un conteneur de hauteur fixe pour tout ce qui s'injecte après coup (pubs, bannières, bandeaux cookies).

Le piège du CLS, c'est l'animation. Une transition faite en top ou height déplace la mise en page. La même en transform ne la déplace pas. J'ai perdu une demi-journée à traquer un décalage de 0,08 sur un menu animé avant de comprendre : ce n'était pas le chargement, c'était le survol. Le CLS ne pardonne pas les raccourcis d'animation.

Réduire l'INP sans tout casser

Ici, pas de recette miracle. Il faut traquer les tâches longues : tout bloc de JavaScript qui monopolise le fil principal plus de 50 ms. La méthode que j'utilise :

• Ouvrir l'onglet « Performance » de Chrome DevTools, enregistrer une interaction réelle (un clic sur un bouton, pas un chargement).
• Repérer les scripts tiers qui s'exécutent au moment de l'action. Les analytics, les chat, les A/B testing sont les coupables habituels.
• Découper : charger le tiers en différé après l'interaction, ou céder la main entre deux traitements (yield to main).

Un cas concret qui m'a marqué : un site dont l'INP dépassait 600 ms uniquement sur mobile. La cause était un script de personnalisation qui recalculait tout le menu à chaque tap, en bloquant 700 ms. En le chargeant après le premier rendu et en le découpant, l'INP est descendu sous les 200 ms. Le poids du JavaScript importait moins que le moment où il s'exécutait.

Comment savoir si son site est réellement en échec

La question revient souvent sous une forme faussée : « mon évaluation Core Web Vitals échoue, c'est grave ? » Oui et non. Un échec sur une métrique dans Search Console signifie que plus de 25 % de vos visites réelles dépassent le seuil. Ça mérite une action, mais pas une panique : ce n'est pas un blocage d'indexation, c'est un facteur de départage qui joue contre vous.

Où lire la vraie évaluation

Trois endroits, dans cet ordre de fiabilité :

• Search Console, rapport « Expérience de chargement » : données de terrain, groupées par type d'URL. La référence.
• PageSpeed Insights : le même terrain en haut, le laboratoire en bas. Regardez d'abord le terrain.
• Le tableau de bord CrUX ou l'API : pour suivre l'évolution sur 28 jours, utile en cours de chantier.

Et un conseil que je répète : ne visez pas le 100. Le score de laboratoire est un indicateur de diagnostic, pas une note à décrocher. Un site à 72 avec un bon LCP terrain et un CLS propre se portera mieux en référencement qu'un site à 98 mais dont l'INP réel dépasse les 400 ms sur mobile. Les chiffres de terrain gagnent toujours.

Placer les Core Web Vitals dans votre travail SEO global

La vitesse, seule, ne fait pas un bon référencement. Elle est une condition de confort, pas le contenu. Un site rapide mais pauvre en réponses utiles restera invisible. Ce que j'observe, c'est que les Core Web Vitals servent surtout de multiplicateur : ils amplifient le reste du travail, contenu et maillage compris, mais ne remplacent rien.

Dans cette logique, un chantier performance se mène en parallèle du contenu, jamais à sa place. Et il faut le mesurer sur la durée : les données de terrain mettent jusqu'à 28 jours à refléter un correctif. Beaucoup abandonnent trop tôt parce que la courbe ne bouge pas en 48 heures. J'ai moi-même resserré les boulons d'un site pendant trois semaines en croyant que rien ne marchait — avant de voir le LCP passer sous les 2,5 s d'un coup, quand la fenêtre glissante a fini par intégrer les pages corrigées.

Le vrai levier, au fond, n'est pas technique. C'est de comprendre qu'une métrique de terrain mesure une expérience vécue, pas une configuration. Vous pouvez truquer un score de laboratoire ; vous ne pouvez pas truquer un utilisateur qui ferme l'onglet. Et c'est précisément pour ça que Google s'y fie.

La prochaine fois que vous regarderez un 94 vert, ouvrez donc l'onglet juste à côté. Le chiffre qui compte n'y est peut-être pas.