Comment corriger de mauvais scores Core Web Vitals ?

Commencez par repérer la métrique en échec, l'appareil concerné et le groupe de pages touché : le rapport Core Web Vitals de Search Console affiche les trois à partir de visites réelles dans Chrome. Corrigez ensuite la cause propre à chaque métrique : pour le LCP, la rapidité d'arrivée de l'image ou du texte principal ; pour l'INP, les longues tâches JavaScript qui retardent les réponses ; pour le CLS, le contenu qui apparaît sans que de l'espace ait été réservé. Les données de terrain couvrent les 28 derniers jours : jugez donc l'effet d'une correction sur un mois.

Étape 1 : identifier ce qui échoue

1. Ouvrez le rapport Core Web Vitals dans Search Console et choisissez Mobile ou Ordinateur ; les deux sont évalués séparément.
2. Ouvrez l'un des problèmes listés, par exemple un problème de LCP sur mobile, pour afficher le groupe d'URL concerné et des exemples d'URL. Tout le groupe partage un même statut, déterminé par sa métrique la plus faible.
3. Passez une URL d'exemple dans PageSpeed Insights pour consulter les données de terrain de cette page à côté d'un test en laboratoire utile au débogage.

Les outils de laboratoire comme Lighthouse ne peuvent pas mesurer l'INP, car personne n'interagit avec la page ; ils indiquent à la place le Total Blocking Time. Pour l'INP, seule la mesure auprès d'utilisateurs réels est fiable.

Comment corriger un LCP trop lent

Le guide d'optimisation du LCP de web.dev décompose le LCP en quatre parties : le temps de réponse du serveur, le délai avant le début du chargement de la ressource principale, son temps de téléchargement et le délai avant son affichage. Commencez par la partie la plus longue :

• Rendez l'image LCP détectable dans le HTML initial au lieu de l'injecter avec JavaScript ou CSS, et donnez-lui fetchpriority="high".
• Ne chargez jamais l'image LCP en différé (lazy loading).
• Allégez-la : dimensions adaptées, format moderne, compression et CDN proche des visiteurs.
• Supprimez les ressources bloquant le rendu : feuilles de style plus légères, aucun script synchrone dans le <head>, rendu côté serveur pour le contenu principal.
• Accélérez la réponse du serveur : réduisez les redirections et permettez la mise en cache des pages en périphérie.

Comment corriger un mauvais INP

Le guide d'optimisation de l'INP décompose chaque interaction en délai d'entrée, temps de traitement et délai de présentation :

• Délai d'entrée : réduisez le JavaScript exécuté pendant le chargement de la page, afin que le thread principal soit disponible quand quelqu'un touche l'écran.
• Temps de traitement : découpez les longs gestionnaires d'événements en tâches plus petites et cédez la main au thread principal, en effectuant d'abord la mise à jour visible et en différant le reste.
• Délai de présentation : gardez un DOM léger, évitez de forcer la mise en page en lisant des styles juste après les avoir modifiés, et utilisez content-visibility pour les pages longues.

Comment corriger un CLS élevé

Le guide d'optimisation du CLS recense les coupables habituels et leurs correctifs :

• Images et vidéos sans dimensions : ajoutez les attributs width et height, ou une propriété CSS aspect-ratio.
• Publicités, contenus intégrés et iframes : réservez leur espace dans la mise en page avant leur chargement.
• Contenu injecté au-dessus du contenu existant : utilisez un espace réservé de la bonne taille, ou insérez le nouveau contenu sous ce que le visiteur est en train de lire.
• Polices web : préchargez les plus importantes pour que le texte ne se réorganise pas tardivement.
• Animations : animez transform plutôt que des propriétés comme top ou left.

Les pages qui peuvent utiliser le cache de navigation avant/arrière du navigateur (back/forward cache) évitent aussi les décalages de mise en page lorsque les visiteurs y reviennent.

Étape 3 : confirmer la correction

Déployez, puis ouvrez le problème dans le rapport Core Web Vitals et lancez la validation. Google surveille le groupe pendant 28 jours ; la validation ne déclenche aucune nouvelle exploration et n'accélère rien, elle vérifie seulement que le problème a disparu. Comme les données de terrain portent sur une fenêtre glissante de 28 jours, attendez-vous à une amélioration progressive du rapport. Pour comprendre ce que mesure chaque métrique, consultez Que signifient LCP, INP et CLS ?.

Comment AutoPSEO vous aide

Le rapport Core Web Vitals d'AutoPSEO représente environ six mois de données hebdomadaires du Chrome UX Report pour votre site ou pour une seule URL, sur mobile, ordinateur ou tablette. Vous voyez ainsi la semaine où une correction a pris effet, ou celle où une mise en production a dégradé les choses, sans attendre la fin de la prochaine fenêtre de 28 jours.