Un client m'appelle un mardi matin, un peu paniqué. « Search Console me dit que mes Core Web Vitals sont en échec. Ça veut dire que je vais perdre tout mon référencement ? » Je lui demande son URL mobile, je lance le test, et là je vois un LCP à 4,8 secondes. Sur un site qui vend des meubles. Autrement dit : il perdait déjà des clients depuis des mois sans le savoir, et le SEO n'était que la partie visible du problème.
C'est toujours comme ça que ça commence. Les Core Web Vitals, c'est-à-dire les trois métriques que Google utilise pour juger de la qualité d'expérience d'une page — rapidité d'affichage, réactivité aux clics, stabilité visuelle —, on les découvre en général par une alerte. Rarement par curiosité. Et une fois qu'on a compris ce qu'elles mesurent, la vraie question arrive : comment on les optimise concrètement ?
Points clés à retenir
- Les Core Web Vitals reposent sur trois mesures : LCP (affichage du plus grand élément), INP (réactivité aux interactions) et CLS (stabilité de la mise en page).
- Les seuils à viser : LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1. Au-delà, la page est considérée comme « à améliorer » ou « médiocre ».
- Il faut distinguer les données de terrain (utilisateurs réels, via Search Console) et les données de laboratoire (Lighthouse, PageSpeed Insights) : les deux ne racontent pas la même histoire.
- Le LCP se corrige le plus souvent en soignant une seule image ou une seule police — pas en réécrivant tout le site.
- Optimiser les Core Web Vitals, c'est d'abord optimiser l'expérience utilisateur ; le bonus SEO vient en plus.
Core Web Vitals : ce que mesurent vraiment ces trois métriques
Avant de toucher à une ligne de code, il faut savoir de quoi on parle. Et là, franchement, la plupart des articles que j'ai lus sautent cette étape pour aller directement aux « astuces ». Résultat : on optimise à l'aveugle.
Le LCP : le moment où l'utilisateur voit enfin quelque chose
Le Largest Contentful Paint mesure le temps nécessaire pour que le plus grand élément visible de la page (une image, un titre, un bloc) s'affiche. C'est le premier signal de « ça charge ». Si votre LCP dépasse 2,5 secondes, l'internaute fixe un écran blanc ou à moitié vide, et il n'a aucune raison de rester.
L'INP : la réactivité une fois la page affichée
L'Interaction to Next Paint a remplacé le FID. Il mesure le délai entre un clic (ou un tap, ou une frappe) et la réaction visuelle de la page. Autrement dit : est-ce que le site répond quand on lui parle ? Un INP supérieur à 200 ms donne cette sensation de site « mou », où l'on clique deux fois parce qu'on croit que rien ne s'est passé.
Le CLS : est-ce que la page saute partout ?
Le Cumulative Layout Shift quantifie les déplacements inopinés des éléments pendant le chargement. Vous visez un bouton « Ajouter au panier », la bannière publicitaire se charge, et vous cliquez sur autre chose. Ceux-là, on les connaît tous. Le CLS mesure à quel point votre mise en page est instable. Objectif : rester sous 0,1.
Mesurer avant d'optimiser : la méthode que la plupart sautent
Là où je vois le plus d'erreurs, ce n'est pas dans les correctifs. C'est dans la mesure. On fait un test PageSpeed Insights, on voit un score rouge, on panique, on bricole. Grave erreur, et je le dis d'autant plus volontiers que je l'ai faite.
Données de terrain contre données de laboratoire
Il existe deux familles de mesures, et elles ne répondent pas à la même question. Les données de laboratoire (Lighthouse dans PageSpeed Insights, l'extension Web Vitals de Chrome) simulent un chargement dans des conditions fixes. Pratique pour reproduire un problème. Les données de terrain viennent des utilisateurs réels sur les 28 derniers jours, agrégées par Google — c'est ce qu'affiche la Search Console dans son rapport « Expérience sur la page ».
C'est ce dernier chiffre qui compte pour Google. Et c'est aussi celui que beaucoup ignorent, parce qu'il n'est pas dans le premier onglet de PageSpeed.
Pourquoi un test Lighthouse peut « mentir »
Lighthouse tourne sur un réseau simulé, un appareil simulé, une page vide de cache. Votre utilisateur réel, lui, est sur un forfait mobile dans un train, avec un cache partiel et une extension qui bloque les scripts. Un score de 95 en labo peut très bien cacher un LCP de 3,2 s en conditions réelles. J'ai déjà vu l'inverse aussi : un site moche en labo qui cartonne sur le terrain parce qu'il est ultra-léger.
Le seuil du 75e percentile
Détail qui change tout : Google ne regarde pas la moyenne, mais le 75e percentile. Si 74 % de vos visites sont rapides et 26 % catastrophiques, vous êtes en échec. La conséquence pratique est simple : chasser les cas lents isolés compte autant que la vitesse moyenne, et les utilisateurs sur mobile en mauvais réseau pèsent lourd dans la balance. Testez toujours en mobile en premier.
Optimiser le LCP : la recette qui fonctionne dans 80 % des cas
Quand un LCP est mauvais, dans mon expérience il y a presque toujours une image trop lourde qui traîne en haut de la page. Pas de la magie, juste un coupable récurrent.
Traiter l'image du LCP comme une priorité absolue
Concrètement, trois actions sur l'image qui occupe le haut de la page :
- Préchargez-la avec
<link rel="preload">pour que le navigateur la demande avant même de découvrir le reste. - Passez-la en WebP ou AVIF : sur une photo hero, on divise le poids par deux à trois sans perte visible.
- Ajoutez fetchpriority="high" sur la balise image, et retirez tout lazy-loading sur cet élément. Le lazy sur l'image LCP est une hérésie : vous demandez au navigateur d'attendre pour charger… ce qu'il doit afficher en premier.
Sur un site de e-commerce que j'ai repris, ces trois points ont fait passer le LCP mobile de 3,7 s à 2,1 s. En une après-midi. Aucune autre modification.
CSS bloquant et polices web
Les autres coupables classiques : une feuille de style énorme qui bloque le rendu, et une police web chargée trop tard qui laisse la page invisible. Pour la police, font-display: swap règle souvent le problème en une ligne — le texte s'affiche avec une police de secours puis se remplace, plutôt que de rester blanc. Pour le CSS, il faut identifier ce qui est critique pour l'affichage initial et charger le reste après.
Optimiser l'INP : quand la page répond avec du retard
L'INP est la métrique la plus difficile à corriger. Le problème est rarement un seul gros fichier : c'est une accumulation de scripts qui s'exécutent au mauvais moment, en particulier pendant que l'utilisateur interagit.
Réduire le JavaScript de tiers
Avant d'écrire du code, ouvrez l'onglet réseau et regardez qui parle. Les outils analytiques, les widgets de chat, les pixels publicitaires, les scripts de chaleur — tout ça s'exécute. Sur un site sur deux que j'audite, un service tiers non utilisé depuis des mois tourne encore silencieusement et coûte cher.
Ma règle : tout script tiers qui ne sert pas directement à la conversion dégage ou passe en chargement différé.
Fractionner le JavaScript
Pour le reste, le principe est le même partout : code splitting. On ne charge pas le JavaScript de la page « contact » quand on est sur la page d'accueil. On ne charge pas le parseur de dates complet pour afficher une seule date. Les frameworks modernes offrent tous un découpage automatique, à condition de ne pas l'avoir désactivé en cours de route — ce qui arrive plus souvent qu'on ne le croit.
Optimiser le CLS : réserver l'espace avant de le remplir
Le CLS est, paradoxalement, la métrique la plus facile à corriger. La cause est presque toujours la même : un élément apparaît sans que la place ait été réservée.
Deux règles et vous éliminez 90 % du problème. Premièrement, toute image et toute iframe (vidéos, cartes, publicités) doit avoir une largeur et une hauteur explicites dans le HTML. Deuxièmement, si vous insérez un bandeau ou une pub en haut de page, réservez-lui un conteneur de taille fixe, sinon tout le contenu se décale au moment de son apparition.
Le reste tient à la discipline : ne changez pas la taille d'un élément au survol, n'injectez pas de texte au-dessus d'un bouton après chargement.
| Métrique | Cause la plus fréquente | Correctif prioritaire |
|---|---|---|
| LCP | Image hero trop lourde | Preload + format AVIF/WebP + fetchpriority high |
| LCP | Police web bloquante | font-display: swap |
| INP | JavaScript tiers trop lourd | Audit des scripts, déchargement ou report |
| INP | Code non fractionné | Code splitting par page |
| CLS | Images sans dimensions | Attributs width et height systématiques |
| CLS | Bannières injectées sans réserve | Conteneur à hauteur fixe |
Suivre les résultats sans se perdre dans les chiffres
Une fois les correctifs déployés, il faut de la patience. Les données de terrain de Search Console sont mises à jour sur une fenêtre glissante de 28 jours : comptez au moins un mois avant de tirer des conclusions. Un chiffre qui remonte doucement, c'est bon signe. Un chiffre qui ne bouge pas alors que le labo s'est amélioré, c'est souvent que le correctif n'a pas atteint les utilisateurs réels — cache mal purgé, CDN qui sert l'ancienne version, ou image preload non prise en compte sur mobile.
Ma routine : je relève le terrain une fois par semaine, pas tous les jours. Sinon on s'agite pour du bruit statistique.
Et puis il y a ce que les chiffres ne disent pas. Le client aux meubles, dont je parlais au début : après trois semaines de correctifs, son LCP était passé sous les 2,5 s. Son trafic n'a pas explosé — je ne vais pas vous vendre un miracle. Mais son taux de rebond mobile a baissé, et ses demandes de devis ont augmenté. Le SEO l'a aidé, sans doute. Ce dont je suis sûr, c'est que ses visiteurs, eux, ont arrêté de fuir.
C'est peut-être ça, la vraie façon de lire les Core Web Vitals : un thermomètre de la patience de vos utilisateurs. Et la patience, elle ne se décrète pas — elle s'optimise.
