Les 3 Core Web Vitals expliqués simplement
Google mesure la qualité de l'expérience utilisateur via trois métriques principales. LCP (Largest Contentful Paint) : le temps nécessaire pour afficher l'élément visuel principal de la page — l'image hero, le titre principal ou le bloc de texte le plus grand. Un bon LCP est inférieur à 2,5 secondes. Au-delà de 4 secondes, Google considère votre page comme "mauvaise" et la pénalise dans les classements. En pratique, le LCP est souvent dégradé par une image hero non optimisée (trop lourde, non convertie en WebP), un hébergement lent, ou des ressources bloquantes (CSS, JavaScript) qui retardent le rendu. INP (Interaction to Next Paint) : remplace le FID (First Input Delay) depuis mars 2024. Mesure la réactivité de votre page à toutes les interactions utilisateur — clics, saisies, scrolls. Un bon INP est inférieur à 200ms. Un INP élevé se ressent concrètement : le clic sur un bouton prend 1 à 2 secondes à réagir, la navigation entre pages est saccadée. CLS (Cumulative Layout Shift) : mesure la stabilité visuelle de la page — à quel point les éléments bougent de façon inattendue pendant le chargement. Score CLS bon : inférieur à 0,1. Un CLS élevé donne l'impression que la page "saute" — un texte que vous vous apprêtez à lire se déplace soudainement parce qu'une image ou une pub s'est chargée.
Comment mesurer vos Core Web Vitals en 5 minutes
Deux outils complémentaires sont indispensables. Google PageSpeed Insights (pagespeed.web.dev) : entrez l'URL de votre page et obtenez en quelques secondes votre score sur 100, vos métriques LCP/INP/CLS, et une liste de recommandations priorisées par impact. Testez systématiquement la version mobile (onglet Mobile) — les scores mobiles pèsent davantage dans l'algorithme Google. Google Search Console : l'onglet "Expérience sur la page" vous donne les données réelles de terrain (données CrUX — Chrome UX Report) sur des vraies visites de vrais utilisateurs sur vos pages. C'est beaucoup plus représentatif que les tests en laboratoire de PageSpeed Insights. Si vos données de terrain montrent "Médiocre" alors que PageSpeed affiche 90/100, c'est que votre hébergement est lent pour les utilisateurs réels, ou que des scripts tiers (analytics, chat, publicités) ralentissent la page en conditions réelles. Troisième outil utile : Lighthouse dans Chrome DevTools (F12 → Onglet Lighthouse). Il vous donne un audit complet de la performance, de l'accessibilité, du SEO et des bonnes pratiques.
Les 7 optimisations qui améliorent le plus le LCP
L'image hero en WebP/AVIF avec dimensions fixes : convertissez votre image principale en format WebP (30% plus léger que JPEG) ou AVIF (50% plus léger), et spécifiez toujours les attributs width et height pour éviter le layout shift pendant le chargement. En Next.js, le composant Image gère tout cela automatiquement. Préchargement de l'image hero : ajoutez une balise link rel="preload" dans le head pour charger l'image hero en priorité absolue avant tout autre élément. Cela peut réduire le LCP de 0,5 à 1,5 seconde. Hébergement sur CDN proche de l'utilisateur : si votre serveur est à Amsterdam et 80% de vos visiteurs sont en France, chaque requête subit une latence inutile. Vercel, Netlify et Cloudflare proposent des CDN mondiaux qui servent les assets depuis les datacenters les plus proches. Suppression des polices bloquantes : le chargement des polices web peut bloquer le rendu. Utilisez font-display: swap pour afficher une police système en attendant et éviter le texte invisible. Élimination des scripts tiers bloquants : chaque pixel de tag manager, chaque script de chat ou de pub bloquants peut rajouter 0,3 à 1 seconde au LCP. Chargez-les en defer ou async, ou en lazy loading après l'interaction utilisateur. Compression serveur : Gzip ou Brotli sur tous les assets textuels (HTML, CSS, JS). Brotli est 15 à 20% plus efficace que Gzip et est supporté par 95%+ des navigateurs modernes. Cache aggressif : mettez en cache les assets statiques (images, CSS, JS) avec un max-age de 31536000 (1 an) et invalider via cache-busting sur les URLs.
Corriger un INP élevé : les principales causes et solutions
Un INP élevé est souvent causé par du JavaScript qui s'exécute sur le thread principal et bloque les interactions. Les coupables les plus fréquents : les analytics et tag managers lourds (Google Tag Manager avec 20+ balises peut ajouter 200 à 500ms au INP), les scripts de chat en temps réel (Intercom, Drift, Crisp — chargez-les uniquement sur les pages où ils sont utiles, ou déclenchez-les après une interaction utilisateur), et les bibliothèques JavaScript inutilement grandes (charger toute la bibliothèque Lodash pour utiliser 3 fonctions est une erreur classique). Solutions techniques concrètes : code splitting pour ne charger que le JavaScript nécessaire à chaque page, lazy loading des composants non critiques avec React.lazy() et Suspense, et exécution des tâches longues en arrière-plan avec Web Workers ou requestIdleCallback pour éviter de bloquer le thread principal. Sur WordPress : l'extension WP Rocket avec son option de différer les scripts JavaScript résout 70% des problèmes INP sans développement. Sur Next.js : le code splitting est automatique et les Server Components ne génèrent pas de JavaScript côté client — c'est l'un des grands avantages du framework pour les performances INP.
Éliminer le CLS : stabiliser visuellement votre page
Le CLS est souvent le plus simple à corriger. Les causes principales : les images sans dimensions définies. Si vous ne spécifiez pas width et height sur vos balises img, le navigateur ne réserve pas d'espace pendant le chargement — quand l'image arrive, elle pousse tout le contenu vers le bas. Solution : toujours spécifier width et height, ou utiliser CSS aspect-ratio. Les publicités et bannières sans espace réservé. Si une bannière pub se charge après le contenu textuel, elle déplace tout. Réservez l'espace exact avec un conteneur CSS de hauteur fixe, même si la pub n'est pas encore chargée. Les polices web qui changent la taille du texte. Le font swap (remplacement d'une police système par la police web chargée) peut provoquer un layout shift si les tailles de caractères diffèrent. Utilisez font-display: optional si le CLS est critique — la police web ne se charge que si elle est déjà en cache. Les injections dynamiques de contenu. Si vous injectez du contenu en haut de la page après le chargement initial (ex: bannière cookie, notification, offre), cela cause un CLS important. Positionnez ces éléments en overlay (position: fixed) pour ne pas décaler le contenu existant.
Résultats concrets : ce qu'une optimisation Core Web Vitals change vraiment
Les chiffres sont éloquents. Sur l'un de nos projets clients (site vitrine d'un cabinet d'avocats à Lyon) : avant optimisation, score Lighthouse 54/100, LCP 4,8s, CLS 0.22, taux de rebond 74%. Après 3 jours d'optimisation (compression images WebP, lazy loading, suppression plugins inutiles) : score 91/100, LCP 1,9s, CLS 0.04, taux de rebond 58%. Résultat après 60 jours : +3 positions sur les mots-clés principaux, +34% de formulaires de contact remplis. Sur un e-commerce Shopify client (prêt-à-porter) : LCP de 6,2s → 2,1s après optimisation du thème et des images. Résultat : taux de conversion +18%, panier moyen en hausse de 12% (les utilisateurs naviguaient davantage dans le catalogue, plus rapide à charger). Ces résultats confirment ce que Google affirme : la corrélation entre performance et conversions est directe et mesurable. Pour chaque site que nous livrons, nous visons systématiquement un score Lighthouse 90+ sur mobile avant le déploiement en production.