Les trois seuils, sans détour
Voici les valeurs que Google publie sur web.dev et qu'il applique dans la Search Console. L'INP y a remplacé le FID en mars 2024.
| Métrique | Ce qu'elle mesure | Vert | Orange | Rouge |
|---|---|---|---|---|
| LCP | Le temps d'affichage du plus gros élément visible à l'écran | 2,5 s ou moins | de 2,5 à 4 s | plus de 4 s |
| INP | Le délai entre une interaction (clic, appui, frappe) et la réaction visible de la page | 200 ms ou moins | de 200 à 500 ms | plus de 500 ms |
| CLS | L'ampleur des décalages de mise en page inattendus (un score, sans unité) | 0,1 ou moins | de 0,1 à 0,25 | plus de 0,25 |
Le détail qui change tout : ces seuils s'appliquent au 75e centile. Pour qu'une URL soit verte, au moins trois visites sur quatre doivent passer sous la barre. Le visiteur sur un vieux smartphone en 4G capricieuse compte autant que vous sur la fibre.
Autre point : mobile et ordinateur sont évalués séparément. Dans la plupart des audits que je mène, c'est le mobile qui est rouge.
Rouge dans la Search Console, 95 dans Lighthouse : qui a raison ?
Les deux outils ne mesurent pas la même chose. Le rapport de la Search Console s'appuie sur les données de terrain du Chrome UX Report (CrUX) : de vraies visites, sur de vrais appareils, agrégées sur 28 jours glissants. Lighthouse simule un seul chargement, dans des conditions de labo. Utile pour diagnostiquer, mais ce n'est pas lui qui vous note.
Deuxième source de confusion : le rapport ne juge pas les URL une par une. Il les regroupe par pages similaires (toutes vos fiches produit, par exemple), et l'état du groupe est celui de sa pire métrique. Un LCP correct avec un CLS médiocre ? Le groupe entier passe en « Médiocre ». Cliquez sur le problème, puis sur une URL d'exemple : vous saurez quelle métrique coince. L'aide officielle du rapport Core Web Vitals détaille cette logique de regroupement.
Ouvrez ensuite PageSpeed Insights sur cette URL d'exemple et lisez d'abord le bloc du haut, celui des utilisateurs réels. Sans assez de trafic sur la page, l'outil affiche les données du site entier. Le score sur 100, plus bas, sert à trouver des pistes, pas à valider.
LCP au-dessus de 2,5 s : trouver l'élément, puis le vrai frein
Première étape, identifier l'élément LCP. PageSpeed Insights le signale dans son diagnostic. Sur un article, c'est souvent l'image à la une ; sur une page d'accueil, un bandeau ou un gros bloc de titre.
Ensuite, on découpe le temps. Google décompose le LCP en quatre morceaux : la réponse du serveur, le délai avant que le navigateur découvre la ressource, son téléchargement, puis son affichage. Chaque morceau a son remède :
- Serveur lent : rien ne s'affiche avant le premier octet. Si c'est là que le temps part, commencez par réduire le TTFB pour ramener la réponse du serveur sous les 200 ms ; la cause est souvent un cache de pages absent ou contourné.
- Image découverte trop tard : une image de fond déclarée en CSS, ou injectée en JavaScript, n'est repérée qu'après coup. Passez-la en vraie balise <img> avec
fetchpriority="high", ou ajoutez un preload si vous n'avez pas le choix. - Image trop lourde : servez la bonne taille avec
srcset, dans un format moderne. Si vous hésitez encore, voyez quel format retenir entre WebP et AVIF, pour la vitesse comme pour le SEO. - Affichage retardé : CSS bloquant, police web en retard, slider qui attend son script.
Le piège que je croise chaque semaine, c'est l'image à la une chargée en lazy loading. Le navigateur la met volontairement de côté, alors que c'est précisément l'élément que Google chronomètre. Retirez loading="lazy" de l'image principale et gardez-le pour tout ce qui se trouve plus bas.
INP au-dessus de 200 ms : le JavaScript qui monopolise le navigateur
L'INP est la métrique qui fait le plus de rouge depuis 2024 : là où le FID ne mesurait que la toute première interaction, l'INP observe toutes celles de la visite et retient l'une des plus lentes.
Ne cherchez pas l'INP dans un test Lighthouse classique : sans clic, pas d'interaction à mesurer. Le labo affiche à la place le Total Blocking Time, un indice indirect. Pour le vrai diagnostic, ouvrez le panneau Performance de Chrome, cliquez sur les boutons, menus, onglets et filtres de la page, et repérez les interactions qui dépassent les 200 ms.
Le coupable est presque toujours du JavaScript qui occupe le fil principal du navigateur : tâches longues, scripts tiers (chat, gestionnaire de balises bien rempli, outil d'A/B test, bandeau de consentement), constructeurs de pages qui chargent tout partout. Les correctifs, du plus rentable au plus technique :
- supprimer les scripts tiers qui ne servent plus (il y en a toujours) ;
- différer le reste avec
defer, ou ne le charger qu'au moment où on en a besoin ; - découper les tâches longues pour rendre la main au navigateur entre deux morceaux (
setTimeout, ouscheduler.yield()là où il est disponible) ; - afficher un retour visuel immédiat (bouton qui change d'état) avant le traitement lourd, puisque l'INP s'arrête à la première mise à jour de l'écran ;
- alléger le DOM : quand une page compte des milliers d'éléments, chaque mise à jour coûte plus cher.
CLS au-dessus de 0,1 : réserver la place avant qu'elle soit prise
Le CLS se corrige souvent en une après-midi, parce que les causes sont toujours les mêmes : un élément arrive sans que sa place ait été réservée, et tout ce qui se trouve dessous saute.
- Images et iframes sans dimensions : ajoutez
widthetheight(le navigateur en déduit le ratio, même en responsive) ou unaspect-ratioen CSS. C'est encore plus vrai pour les images différées, qui arrivent pendant le défilement : si vous avez mis en place le chargement différé de vos images sans gêner leur indexation, vérifiez que les dimensions suivent. - Publicités, vidéos intégrées, widgets : réservez-leur une hauteur minimale fixe.
- Bandeaux injectés en haut de page (cookies, promo, invitation à télécharger l'appli) : affichez-les en superposition au lieu de pousser le contenu.
- Polices web : le passage de la police de secours à la vraie police décale le texte. Préchargez la police principale et ajustez la police de secours (
size-adjust) pour qu'elles occupent la même place.
Bonne nouvelle, un décalage qui suit de près une action de l'utilisateur (un accordéon qu'il ouvre) n'est pas compté, pas plus que les animations faites avec transform.
Valider la correction, puis patienter
Une fois le correctif en ligne, retournez dans le rapport, ouvrez le problème et cliquez sur « Valider la correction ». La Search Console lance une période de surveillance de 28 jours, le temps que les anciennes visites sortent de la fenêtre de données. Relancer tous les trois jours n'accélère rien.
Si la validation échoue, une partie des URL du groupe reste au-dessus du seuil. Le plus souvent, un modèle de page a été oublié (les catégories, quand vous n'avez corrigé que les articles).
Retenez l'ordre : repérer la métrique et le groupe dans la Search Console, diagnostiquer en labo, corriger le modèle de page plutôt que l'URL isolée, puis laisser 28 jours de vraies visites confirmer le vert.