Core Web Vitals 2024 : optimiser LCP, INP et CLS

Depuis mars 2024, Google a remplacé la métrique FID par INP dans son trio des Core Web Vitals. Ces trois indicateurs — LCP, INP et CLS — pèsent directement dans le classement SEO et conditionnent l'expérience utilisateur perçue. Voici ce qu'ils mesurent vraiment, et comment les améliorer sans refondre votre site de zéro.

LCP — Largest Contentful Paint

Pourquoi votre LCP est mauvais

Dans 80% des cas, le coupable est une image hero non optimisée. Un JPG de 2 MB chargé sans fetchpriority="high", sans preload, sans format moderne — le LCP grimpe à 4 ou 5 secondes immédiatement. Les autres causes habituelles : un serveur lent (TTFB > 600ms), un CDN absent, une font qui bloque le rendu.

Comment le corriger

• Convertir l'image hero en AVIF ou WebP : gain typique 40 à 70% du poids vs JPG
• Ajouter <link rel="preload" as="image"> sur l'image LCP avec imagesrcset et imagesizes
• Mettre fetchpriority="high" sur le tag <img> du hero
• Préciser width et height dans le HTML pour réserver l'espace
• Self-host des polices Google avec font-display: swap et <link rel="preload" as="font" crossorigin>
• Activer la compression Brotli au niveau serveur (gain 15 à 25% sur HTML/CSS/JS vs Gzip)
• Mettre en place un CDN (Cloudflare gratuit suffit dans 90% des cas) pour rapprocher les assets du visiteur

INP — Interaction to Next Paint

Pourquoi votre INP est mauvais

L'INP remplace l'ancien FID en mesurant toutes les interactions sur la page (pas juste la première). Le coupable habituel : du JavaScript trop lourd. Scripts tiers (Google Tag Manager, pixels Facebook, chats, popups), bundles React/Vue mal optimisés, listeners qui font des calculs sur chaque scroll. Sur WordPress avec 15 plugins, l'INP dépasse souvent les 500ms — un véritable carton rouge pour Google.

Comment le corriger

• Auditer les scripts tiers et virer ceux qui n'apportent rien (Hotjar inactif, anciens pixels publicitaires, plugins WordPress non utilisés)
• Charger les scripts non-critiques en defer ou async — jamais inline en haut de page
• Reporter le chargement de Google Tag Manager après load ou via Partytown si vraiment nécessaire
• Throttler les event listeners coûteux (scroll, mousemove, resize) avec requestAnimationFrame
• Sur React : utiliser useDeferredValue, startTransition, et éviter les rerendus inutiles
• Découper les bundles JS volumineux avec du code splitting
• Sur WordPress : utiliser un cache (WP Rocket, LiteSpeed Cache) qui sait minifier et différer les scripts

CLS — Cumulative Layout Shift

Pourquoi votre CLS est mauvais

Le CLS dérape quand des éléments apparaissent ou se déplacent après que la page semble chargée. Vous lisez une phrase, et hop, une image se charge au-dessus et tout descend. Vous cliquez sur un bouton, et une publicité prend sa place — vous cliquez sur la pub. C'est rageant pour l'utilisateur et puni par Google.

Comment le corriger

• Toujours préciser width et height sur les <img>, <video>, <iframe> — le navigateur réserve l'espace exact
• Utiliser aspect-ratio en CSS pour les conteneurs d'images responsives
• Ne jamais insérer dynamiquement du contenu au-dessus du fold sans réserver la place (bannières cookies en bas, pas en haut)
• Charger les fonts avec font-display: optional ou swap + size-adjust pour limiter le saut de typographie
• Pour les publicités : réserver un conteneur de hauteur fixe avec min-height
• Animer uniquement transform et opacity, jamais top/left/width/height qui déclenchent du reflow

Comment mesurer ses Core Web Vitals

Trois outils complémentaires à utiliser dans cet ordre :

• PageSpeed Insights (pagespeed.web.dev) : donne les scores en data labo + data terrain (CrUX, données réelles des utilisateurs Chrome)
• Lighthouse dans Chrome DevTools : pour itérer rapidement pendant le développement
• Google Search Console > Signaux Web Essentiels : la source de vérité long terme. C'est ce que Google utilise pour vous noter

Astuce importante : les données terrain (CrUX) comptent pour le SEO, pas les données labo. Une page peut avoir un score Lighthouse de 95 et un mauvais CrUX si vos vrais visiteurs ont une connexion lente ou des appareils anciens. Optimisez en pensant aux smartphones milieu de gamme sur 4G.

L'ordre de priorité quand on a peu de temps

Si vous ne deviez optimiser qu'une seule chose : les images. Sur 95% des sites que nous auditons, c'est ce qui débloque le LCP le plus vite et le plus visiblement.

Ensuite, l'élimination des scripts tiers inutiles. Un tag Google Tag Manager qui charge 15 trackers ralentit l'INP même quand l'utilisateur ne fait rien.

Enfin, les dimensions explicites sur tous les éléments dynamiques. C'est rapide à faire et ça stabilise le CLS immédiatement.

Faut-il vraiment 100/100 partout ?

Honnêtement, non. Le SEO récompense les sites qui passent le seuil "Good" sur les 3 Core Web Vitals (LCP < 2,5s, INP < 200ms, CLS < 0,1). Au-delà, le gain SEO est marginal — le temps investi est mieux rentabilisé ailleurs (contenu, backlinks, conversion). Visez les seuils verts, pas le 100/100 dogmatique. Sur un budget contraint, mieux vaut un site à 92 qui convertit bien qu'un site à 100 vide de contenu.