Les Core Web Vitals mesurent l’expérience utilisateur réelle sur une page, pas la performance théorique d’un serveur. En 2026, trois métriques comptent, une a changé il y a un an (FID est mort, INP l’a remplacé en mars 2024), et Google a clarifié en février 2026 une limite de taille de fichier qui a créé plus de bruit que nécessaire. Voici ce qui compte vraiment et où sont les problèmes les plus fréquents sur les sites que j’audite.

Les trois métriques actuelles

LCP : Largest Contentful Paint

Le LCP mesure le temps de chargement du plus grand élément visible dans le viewport : généralement une image hero, une vidéo ou un grand bloc de texte. Seuil cible : sous 2,5 secondes pour 75% des chargements. Selon le Web Almanac 2025, seulement 62% des pages mobiles atteignent ce seuil, c’est la métrique la plus difficile à passer des trois.

C’est aussi celle où je trouve le plus souvent des problèmes sur les sites que j’audite. La cause numéro un : une image hero non optimisée. Une image de 2,4 Mo servie en JPEG au lieu de 120 Ko en WebP, sans attribut loading="eager" ni fetchpriority="high", peut faire passer le LCP de 1,8 à 5 secondes à elle seule. Sur les sites WordPress avec Elementor ou un page builder équivalent, le slider ou l’image de fond above the fold est systématiquement à vérifier en premier.

Deuxième cause fréquente : les scripts tiers qui bloquent le rendu. Un tag Google Ads ou un widget de chat chargé de façon synchrone avant le contenu principal retarde le LCP même si l’image est bien optimisée. La solution : charger ces scripts en defer ou async, et les déplacer en fin de <body>.

INP : Interaction to Next Paint

INP a remplacé FID en mars 2024. La différence est importante : FID mesurait uniquement le délai de la première interaction, INP mesure la réactivité de la page à toutes les interactions pendant toute la durée de la visite. C’est un critère beaucoup plus exigeant.

Seuil cible : sous 200ms. Selon le Web Almanac 2025, 77% des pages mobiles passent ce seuil, c’est la métrique la mieux maîtrisée des trois, mais elle peut se dégrader rapidement sur des sites avec beaucoup de JavaScript.

Les principales causes de mauvais INP : JavaScript lourd qui monopolise le thread principal (plugins WordPress empilés, bibliothèques non utilisées), événements click ou scroll mal optimisés, et contenu dynamique injecté au moment de l’interaction. Sur WordPress, le passage à un thème léger et la désactivation des plugins inutiles a souvent plus d’impact sur l’INP qu’une optimisation technique fine.

CLS : Cumulative Layout Shift

Le CLS mesure la stabilité visuelle, les éléments qui bougent pendant le chargement. Seuil cible : sous 0,1. C’est la métrique la mieux maîtrisée globalement (81% des pages mobiles passent selon le Web Almanac 2025), mais elle reste un problème récurrent sur certains types de sites.

Causes fréquentes : images sans attributs width et height définis (le navigateur ne réserve pas d’espace avant le chargement), bannières cookies ou publicités chargées dynamiquement qui poussent le contenu vers le bas, polices web qui swappent au chargement avec une fonte de substitution de taille différente.

Ce que Screaming Frog et PageSpeed Insights ne montrent pas de la même façon

Un point de confusion fréquent sur les CWV : les scores PageSpeed Insights (laboratoire) et les données GSC (terrain) peuvent diverger significativement.

PageSpeed Insights mesure une simulation en conditions contrôlées. Les données GSC (rapport Expérience de page > Core Web Vitals) mesurent le 75e percentile des chargements réels des utilisateurs Chrome sur les 28 derniers jours. Une page peut afficher 85/100 sur PageSpeed et être marquée « Mauvais » dans GSC parce que les utilisateurs mobiles sur des connexions 3G en régions dégradent la distribution réelle.

C’est toujours les données GSC terrain qui comptent pour le classement. PageSpeed Insights est un outil de diagnostic, pas la mesure de référence.

La limite des 2 Mo : ce qui a vraiment changé en février 2026

En février 2026, Google a mis à jour sa documentation Googlebot pour préciser que la limite de fichier HTML prise en compte pour l’indexation est de 2 Mo (non compressé). Cette annonce a généré beaucoup de bruit dans la communauté SEO, avec des titres sur une « réduction de 86% de la limite de crawl ».

La réalité est plus nuancée. Google a précisé qu’il s’agit d’une clarification de documentation, pas d’un changement de comportement. La limite de téléchargement (fetch) reste à 15 Mo. La limite de 2 Mo s’applique au traitement pour l’indexation. Et la formulation a été adoucie dans la documentation à « par exemple, 2 Mo », ce qui suggère une limite moins rigide que les premiers titres ne le laissaient entendre.

Ce qui est réel et important : la limite s’applique à la taille HTML non compressée. Une page peut se transférer en 150 Ko compressé via GZIP mais peser 2,5 Mo non compressé. Google ne signale pas dans GSC quand une page est tronquée à cette limite. Le contenu après 2 Mo peut ne pas être indexé sans aucune alerte.

Qui est vraiment concerné. La page HTML moyenne pèse environ 22 Ko selon HTTP Archive : soit 90 fois moins que la limite. Pour la grande majorité des sites, ce changement n’a aucun impact. Les sites potentiellement concernés sont les sites e-commerce avec des pages catégories très longues (produits en masse chargés dans le HTML), les pages avec des milliers d’avis clients intégrés directement dans le HTML, et les sites construits avec des page builders qui génèrent des templates HTML très verbeux.

Comment vérifier. Dans Screaming Frog, la colonne « HTML Size » affiche la taille non compressée. Toute page dépassant 1,5 Mo mérite une investigation. Dans Chrome DevTools, la différence entre « transferred » (compressé) et « resource » (non compressé) permet de mesurer l’écart. Un script Python de vérification est aussi applicable sur des exports crawl.

Ce que ça change pour les LLMs. Un point peu discuté : les moteurs génératifs (ChatGPT, Perplexity, Claude) dépendent aussi de pages HTML propres et entièrement crawlables pour générer leurs réponses. Une page tronquée à 2 Mo peut être incomplètement représentée dans les réponses IA, même si elle est bien positionnée sur Google. C’est un argument supplémentaire pour garder des pages HTML legères.

Les optimisations à prioriser

Sur les sites que j’audite, l’ordre de priorité est toujours le même :

• Images en premier. Conversion en WebP ou AVIF (gain moyen de 60-80% sur le poids), dimensions explicites sur toutes les images pour éviter le CLS, loading="lazy" sur les images below the fold, fetchpriority="high" sur l’image LCP. C’est là que le gain est le plus rapide et le plus visible.
• Scripts en second. Audit des scripts tiers (tag manager, pixels publicitaires, chats, widgets) et passage en defer ou async. Sur WordPress, désactiver les plugins inutilisés, chaque plugin actif charge potentiellement du CSS et du JS sur toutes les pages même s’il n’est utilisé que sur une page. Un plugin de cache bien configuré (WP Rocket, SiteGround Optimizer) règle la majorité des problèmes de second.
• HTML size en troisième. Vérification de la taille non compressée sur les pages stratégiques, surtout sur les sites e-commerce et les pages générées dynamiquement avec beaucoup de contenu.

Les outils pour mesurer : PageSpeed Insights pour le diagnostic, GSC (Expérience de page) pour les données terrain réelles, Screaming Frog pour l’audit à grande échelle sur tout le domaine.

Si tu veux évaluer l’état des Core Web Vitals de ton site et identifier les corrections prioritaires, je suis disponible pour un audit technique.