Core Web Vitals : pourquoi ces métriques peuvent faire mal à votre visibilité
Depuis que Google a officiellement intégré les Core Web Vitals à son algorithme de classement en 2021, puis renforcé leur poids lors des mises à jour successives, ces indicateurs de performance sont devenus incontournables pour quiconque souhaite maintenir ou améliorer son positionnement dans les pages de résultats. Pourtant, en 2025, de nombreux sites — y compris ceux gérés par des agences françaises expérimentées — continuent de commettre des erreurs qui leur coûtent des positions précieuses. Le problème n’est pas toujours un manque de connaissance théorique, mais plutôt une mauvaise priorisation, ou des choix techniques qui semblent anodins en surface et s’avèrent dévastateurs en pratique. Cet article passe en revue les erreurs les plus fréquentes et les plus coûteuses, avec des pistes concrètes pour les corriger.
LCP mal optimisé : l’erreur numéro un sur les sites vitrines et e-commerce
Le Largest Contentful Paint (LCP) mesure le temps nécessaire pour que l’élément visuel le plus grand de la page — souvent une image hero, un bloc texte important ou une vidéo — soit rendu à l’écran. Google recommande un LCP inférieur à 2,5 secondes. C’est une cible qui paraît raisonnable, mais qui se révèle difficile à atteindre dès lors qu’on empile les mauvaises pratiques. L’erreur la plus classique ? Charger l’image hero via CSS en background-image plutôt qu’en balise <img> avec l’attribut fetchpriority="high". Le navigateur ne peut pas précharger ce qu’il ne voit pas dans le HTML initial. Résultat : l’image arrive tard, le LCP s’envole, et Google enregistre une mauvaise expérience utilisateur. Une autre erreur fréquente consiste à héberger les images sur un CDN mal configuré, ou pire, sur un serveur mutualisé dont le Time to First Byte (TTFB) dépasse allègrement les 600 ms. En France, de nombreuses PME travaillent encore avec des hébergeurs bas de gamme sans réaliser l’impact direct sur leurs Core Web Vitals. Corriger le LCP passe souvent par trois actions prioritaires : optimiser le serveur ou migrer vers un hébergement performant, précharger l’image LCP via une balise <link rel="preload"> dans le <head>, et convertir les images au format WebP ou AVIF.
CLS : les décalages visuels invisibles qui pénalisent l’expérience
Le Cumulative Layout Shift (CLS) est probablement la métrique la plus sournoise des Core Web Vitals. Elle mesure les décalages inattendus de mise en page pendant le chargement de la page. Un CLS inférieur à 0,1 est considéré comme bon. Or, beaucoup de sites dépassent ce seuil sans que les équipes s’en rendent compte, simplement parce que les décalages sont parfois subtils et ne se manifestent pas de la même façon selon les appareils. Les erreurs les plus courantes incluent l’absence de dimensions explicites sur les balises <img> et <video>, ce qui oblige le navigateur à recalculer la mise en page une fois l’élément chargé. Les publicités et les iframes sans espace réservé sont également des coupables habituels. Sur les sites WordPress — qui représentent une part massive du parc web français — les thèmes premium mal codés ou les plugins d’optimisation d’images mal configurés sont souvent responsables de CLS élevés. Une pratique recommandée en 2025 : auditer régulièrement ses pages dans Google Search Console, qui remonte désormais des alertes assez précises sur les éléments responsables des décalages. L’utilisation de l’outil Web Vitals extension de Chrome en complément permet d’identifier visuellement les éléments fautifs sur mobile comme sur desktop.
INP : la nouvelle métrique qui surprend encore beaucoup d’équipes
Depuis mars 2024, le Interaction to Next Paint (INP) a remplacé le First Input Delay (FID) comme troisième Core Web Vital officiel. Cette transition a pris de court de nombreuses équipes SEO et développement, notamment en France où la mise à jour des pratiques peut parfois accuser quelques mois de retard. L’INP mesure la réactivité globale d’une page face aux interactions utilisateur : clics, touches, saisies dans des formulaires. Un bon INP doit être inférieur à 200 ms. La principale source de problème ? Un thread principal JavaScript surchargé. Chaque fois qu’un utilisateur interagit avec la page, le navigateur doit interrompre ce qu’il fait pour traiter l’interaction. Si des scripts lourds monopolisent le thread, la réponse se fait attendre. Les erreurs les plus coûteuses ici concernent les sites qui accumulent des dizaines de scripts tiers — outils de tracking, chatbots, outils de personnalisation, widgets sociaux — sans jamais auditer leur impact réel. En agence, il est devenu indispensable de systématiser l’audit INP dans les livrables de performance, au même titre que le LCP et le CLS. Des outils comme Chrome DevTools avec le panneau Performance Insights ou WebPageTest permettent de repérer les long tasks responsables des mauvais scores INP.
Les erreurs de mesure : confondre lab data et field data
Une erreur conceptuelle que l’on retrouve souvent, même dans des agences bien rodées, consiste à piloter l’optimisation Core Web Vitals uniquement à partir des données de laboratoire — celles de Lighthouse, PageSpeed Insights en mode simulé, ou GTmetrix. Ces outils sont utiles pour le diagnostic, mais ils ne reflètent pas ce que Google mesure réellement. Le moteur utilise les données de terrain (field data) issues du Chrome User Experience Report (CrUX), qui agrège les vraies expériences des utilisateurs Chrome sur votre site. Il n’est pas rare d’avoir un score Lighthouse proche de 90/100 et pourtant un statut « À améliorer » dans Google Search Console, simplement parce que les conditions réelles d’utilisation — connexions mobiles 4G, appareils d’entrée de gamme, utilisateurs en zone rurale — sont bien plus défavorables que le scénario simulé. En France, où une part non négligeable des internautes accède au web depuis des smartphones milieu de gamme avec une connexion mobile variable, cet écart est particulièrement marqué. La bonne pratique consiste à toujours croiser les données Lighthouse avec les rapports CrUX disponibles dans Search Console, et à utiliser le Real User Monitoring (RUM) si le volume de trafic le permet.
Comment prioriser les corrections sans paralyser sa roadmap
Face à la liste des erreurs possibles, beaucoup de responsables marketing et de chefs de projet se sentent dépassés. La bonne nouvelle, c’est qu’une approche méthodique permet d’obtenir des gains significatifs rapidement, sans tout refondre. La première étape consiste à identifier les pages prioritaires : celles qui génèrent le plus de trafic organique et qui présentent les pires scores CrUX. Ce sont elles qui ont le plus d’impact sur le classement global du site. Ensuite, il faut traiter les quick wins en premier : ajout des dimensions sur les images, activation de la compression Brotli ou Gzip, mise en cache navigateur, préchargement de la police principale. Ces actions sont souvent réalisables en quelques heures et peuvent faire progresser significativement le LCP et le CLS. Pour les problèmes plus profonds — refonte du chargement JavaScript, révision de l’architecture de thème, migration d’hébergement — il vaut mieux les intégrer dans une roadmap trimestrielle avec des jalons clairs. En agence, cette approche en deux vitesses (corrections immédiates + plan d’action long terme) est celle qui rassure le mieux les clients tout en produisant des résultats mesurables. En 2025, les Core Web Vitals ne sont plus une option technique réservée aux développeurs : ils sont devenus un enjeu business à part entière, directement lié à la visibilité organique et au taux de conversion.
