Guide : Les Core Web Vitals expliqués et comment les améliorer

Pourquoi les Core Web Vitals comptent en 2026 (informations vérifiées en avril 2026, susceptibles d’évoluer) ?

Depuis 2021, Google utilise les Core Web Vitals (LCP, INP, CLS) comme signal de classement. Mauvais score = perte de rang. En mars 2024, l’INP a remplacé le FID. En 2026, le seuil « bon » sur 75 % des sessions reste l’objectif Google. Cet article détaille les 3 métriques et comment les améliorer.

Core Web Vitals : les métriques qui comptent pour Google

Depuis 2021, Google utilise les Core Web Vitals comme facteur de classement. Ces 3 métriques mesurent l’expérience utilisateur réelle de votre site.

Comment mesurer vos Core Web Vitals

Données de terrain (utilisateurs réels)

• Google Search Console → Expérience → Signaux Web essentiels
• PageSpeed Insights → section « Données de terrain »
• Chrome UX Report (CrUX) via BigQuery

Données de laboratoire (tests simulés)

• PageSpeed Insights → section « Données de labo »
• Chrome DevTools → onglet Performance
• Lighthouse (intégré à Chrome)

Améliorer le LCP (Largest Contentful Paint)

Le LCP mesure le temps d’affichage de votre plus grand élément visible (souvent une image hero ou un titre).

Solutions par ordre de priorité

1. Optimiser l’image principale

   <img src= »hero.webp » width= »1200″ height= »600″

     fetchpriority= »high » decoding= »async »

     alt= »Description » />

2. Utiliser un CDN — Cloudflare gratuit avec serveurs en Afrique
3. Précharger les ressources critiques

   <link rel= »preload » href= »hero.webp » as= »image » />

   <link rel= »preconnect » href= »https://fonts.googleapis.com » />

4. Réduire le TTFB — cache serveur, mise à niveau hébergement

Améliorer le INP (Interaction to Next Paint)

Le INP remplace le FID depuis mars 2024. Il mesure la réactivité de votre site aux clics, taps et saisies clavier.

• Réduire le JavaScript bloquant — différez les scripts non essentiels avec defer ou async
• Diviser les longues tâches — aucune tâche JS ne devrait bloquer le thread principal plus de 50ms
• Supprimer le JS inutile — désactivez les plugins WordPress non essentiels
• Utilisez le lazy loading pour les widgets et éléments interactifs hors écran

Améliorer le CLS (Cumulative Layout Shift)

Le CLS mesure la stabilité visuelle. Avez-vous déjà cliqué sur un bouton et, au moment du clic, la page a bougé et vous avez cliqué ailleurs ? C’est un mauvais CLS.

Causes courantes et solutions

Checklist WordPress pour les Core Web Vitals

Pour explorer plus loin

• Optimiser la vitesse pour le SEO
• Lazy loading images
• Référence : web.dev — Core Web Vitals
• INP : web.dev — Interaction to Next Paint
• Outil : PageSpeed Insights

Comprendre les Core Web Vitals version 2025

Les Core Web Vitals sont les trois métriques de performance que Google utilise pour juger l’expérience utilisateur d’une page. Depuis mars 2024, Interaction to Next Paint (INP) a remplacé First Input Delay. La trilogie 2025 est donc : LCP (Largest Contentful Paint) sous 2,5 secondes, INP sous 200 ms, CLS (Cumulative Layout Shift) sous 0,1.

Ces seuils définissent la zone bonne. Entre 2,5 et 4 secondes pour LCP, 200 et 500 ms pour INP, 0,1 et 0,25 pour CLS, vous êtes en zone à améliorer. Au-delà, c’est médiocre. Ce tutoriel mesure votre site, identifie le goulot, applique les correctifs et vérifie le gain en sept étapes.

Étape 1. Mesurer avec PageSpeed Insights et CrUX

Ouvrez pagespeed.web.dev et collez l’URL de votre page la plus visitée. PageSpeed renvoie deux blocs : Données réelles (issues du Chrome User Experience Report — CrUX, agrégat 28 jours) et Données de laboratoire (test Lighthouse instantané). Seules les données CrUX comptent pour le classement Google.

Si la mention « Aucune donnée terrain » apparaît, votre trafic est trop faible pour CrUX (seuil approximatif 1 000 visites/mois). Dans ce cas, déployez Web Vitals Library (npm install web-vitals) et envoyez les métriques à Google Analytics 4 ou Plausible. Vous reconstruisez votre propre CrUX en deux semaines.

Étape 2. Diagnostiquer le LCP avec l’onglet Performance de Chrome

Ouvrez votre site dans Chrome, F12 > onglet Performance, cochez Disable cache et lancez l’enregistrement. Sur le graphique, repérez le marqueur LCP : c’est l’horodatage où le plus grand élément visible (héro image, titre H1, vidéo) finit de peindre.

Trois causes dominantes en 2025 :

• Image héro non optimisée (PNG 1,2 Mo livrée en JPEG progressif aurait fait 180 Ko).
• Fonte web bloquante (FOIT) qui repousse le rendu du texte.
• Balise <script> tierce (chat, A/B test) qui retarde le parser HTML.

Triez par cause avant d’agir. Réparer une image inutilement ne déplace pas LCP si le bloqueur est une fonte.

Étape 3. Optimiser les images du LCP

Convertissez l’image héro en AVIF avec fallback WebP. Sur un VPS Linux, installez ImageMagick et exécutez :

magick hero.jpg -quality 60 hero.avif
magick hero.jpg -quality 75 hero.webp

Servez les trois formats avec <picture> :

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="..."
       width="1200" height="600"
       fetchpriority="high" decoding="async">
</picture>

Trois directives critiques : width et height explicites (réservent l’espace, gain CLS), fetchpriority="high" (indique au navigateur que cette image est le LCP), et un format moderne. Gain mesuré sur sites WordPress moyens : LCP de 3,8 s à 1,9 s, soit -50 %.

Étape 4. Réduire l’INP en allégeant le JavaScript bloquant

INP mesure le délai entre une interaction (clic, frappe, tap) et la prochaine peinture qui répond visuellement. Au-delà de 200 ms, l’utilisateur perçoit un lag. Le coupable principal : un long task JavaScript supérieur à 50 ms qui occupe le thread principal au moment où l’utilisateur clique.

Trois leviers immédiats :

1. Différer le JavaScript non critique avec <script defer> ou <script type="module">.
2. Charger en lazy les widgets sociaux et chats : remplacez le snippet inline par un placeholder cliquable qui charge le vrai widget seulement après le premier clic.
3. Découper les long tasks avec scheduler.yield() (disponible Chrome 129+) ou setTimeout(fn, 0) en fallback.

Un thème WordPress moyen charge 8 à 12 plugins JavaScript. Auditez avec WP Rocket ou Asset CleanUp et désactivez les scripts qui n’ont rien à faire sur la page d’accueil.

Étape 5. Stabiliser la mise en page pour annuler le CLS

CLS pénalise tout déplacement inattendu d’élément visible. Les fautifs récurrents :

• Image sans dimensions explicites : ajoutez toujours width et height.
• Bannière de cookies qui pousse le contenu vers le bas : utilisez position: fixed en bas de viewport.
• Annonces AdSense ou bannières dynamiques : réservez l’emplacement avec min-height.
• Fontes web qui changent la taille du texte au chargement : utilisez font-display: optional ou la propriété CSS size-adjust.

Pour mesurer pendant le développement, ouvrez Performance Insights (DevTools Chrome 130+), filtre Layout shifts. Chaque shift est listé avec sa cause exacte : DOM ajouté, taille modifiée, ressource chargée tardivement.

Étape 6. Activer le caching agressif côté serveur et CDN

Sur WordPress, installez WP Rocket (49 USD/an pour un site, environ 30 000 FCFA) ou la combinaison gratuite W3 Total Cache + Cloudflare Free. Activez la minification HTML/CSS/JS, la combinaison conditionnelle, le préchargement des liens internes au survol.

Sur Cloudflare, activez Auto Minify (HTML, CSS, JS), Brotli, Early Hints et le mode Speed > Optimization > Cache by Device Type. Pour une audience Afrique de l’Ouest, le PoP Cloudflare le plus proche reste Lagos ou Abidjan ; vérifiez le Time to First Byte avec curl -w "%{time_starttransfer}".

Côté hébergement, un mutualisé Hostinger Premium à 2,99 USD/mois est annoncé attractif mais ses performances dégradent au-delà de 5 000 visites jour. Pour une vitrine professionnelle vise un VPS o2switch (en France, 5 EUR/mois HT) ou un Kinsta plan WordPress Hosting (35 USD), bien plus stables.

Étape 7. Re-mesurer et surveiller en continu

Patientez 28 jours après vos correctifs avant de juger CrUX (la fenêtre roulante doit se renouveler). En interne, posez la Web Vitals Library :

import {onLCP, onINP, onCLS} from 'web-vitals';

function send(metric){
  navigator.sendBeacon('/vitals',
    JSON.stringify(metric));
}
onLCP(send); onINP(send); onCLS(send);

Cette boucle de mesure remonte chaque visite réelle vers votre endpoint. Vous identifiez immédiatement une régression après un déploiement, sans attendre la mise à jour CrUX. Couplé à un Datadog Synthetics ou un simple cron uptime-kuma, vous tenez vos seuils Google sans dériver.

Pour explorer plus loin sur la chaîne d’optimisation, lisez notre tutoriel Excel Copilot qui aide à analyser les exports CrUX, ou Automatiser avec Zapier pour alerter Slack dès qu’une page sort de la zone verte.

Optimisation images AVIF et WebP : seuils et fallbacks

L’image represente en moyenne 50 % du poids d’une page web. Sur un site marchand a Dakar dont les visiteurs accedent souvent en 3G ou 4G aux Almadies ou en banlieue, l’optimisation images peut diviser par trois le LCP (Largest Contentful Paint) et faire passer la note Core Web Vitals de mediocre a bonne. AVIF, finalise en 2019 et adopte par Chrome, Firefox, Safari et Edge depuis 2023, offre une compression 30 a 50 % superieure a WebP a qualite visuelle equivalente. Sur une photo produit de 380 KB en JPEG, la version AVIF tombe a 95 KB, la version WebP a 145 KB.

L’integration en HTML utilise la balise picture avec sources empilees. La syntaxe correcte declare AVIF en premier (le navigateur prend la premiere source supportee), WebP en deuxieme, JPEG en fallback. Pour les images critiques au-dessus du fold, ajouter fetchpriority="high" et loading="eager" sur la balise img de fallback. Pour les images sous le fold, loading="lazy" et decoding="async" liberent le thread principal.

Le pipeline de generation se branche typiquement sur sharp (Node.js) ou ImageMagick. Une commande comme cwebp -q 75 source.jpg -o sortie.webp et avifenc --min 25 --max 35 source.jpg sortie.avif produit des sorties optimisees. Le seuil de qualite 75 pour WebP et le couple 25-35 pour AVIF representent le bon compromis qualite/poids pour la photo produit. Pour les illustrations vectorielles, SVG reste imbattable et n’a pas besoin d’AVIF.

Preload critique et budget de ressources : structurer l’ordre de chargement

Le preload des ressources critiques accelere drastiquement le LCP. Pour une page d’accueil dont l’image hero est l’element LCP, ajouter dans le head <link rel="preload" as="image" href="hero.avif" type="image/avif" fetchpriority="high"> declenche le telechargement avant meme le parsing du body. Sur les sites WordPress, le plugin Rank Math gere bien le preload des images featured, mais pour un controle fin, un theme custom permet de cibler precisement la ressource critique.

Le budget de ressources fixe une discipline. Pour une page de contenu typique sur ITSkillsCenter, l’objectif est : moins de 200 KB total sur le LCP, moins de 1,5 Mo total page, moins de 50 requetes HTTP, moins de 200 KB de JavaScript bloquant. Ces seuils permettent de tenir un LCP sous 2,5 secondes meme en 4G congestionnee. Le preload des polices web critiques avec <link rel="preload" as="font" type="font/woff2" crossorigin> evite le FOIT (Flash Of Invisible Text) qui penalise la perception de vitesse.

Sur un projet pour un media en ligne a Abidjan, l’application stricte de ces regles a fait passer le LCP de 4,8 a 1,9 secondes sur le P75 mobile, et le score CrUX du site est passe de 38 a 82 en six semaines. La serie SEO technique approfondit les diagnostics Lighthouse et WebPageTest pour cibler les optimisations a fort impact.

Mesure terrain via CrUX : interpreter les donnees reelles plutot que synthetiques

Lighthouse fournit une vue synthetique d’un point de mesure unique. CrUX (Chrome User Experience Report) collecte les vraies metriques aupres des utilisateurs reels qui visitent le site. Le rapport CrUX agrege les donnees sur 28 jours glissants et expose trois quartiles : P75, P90, P95. Le P75 est la metrique de reference pour Core Web Vitals : si 75 % des visiteurs experimentent un LCP sous 2,5 secondes, la page est consideree comme « Good ».

L’acces se fait via plusieurs canaux. Le rapport Search Console expose les Core Web Vitals par groupe d’URLs. PageSpeed Insights affiche les donnees CrUX en plus de Lighthouse. Pour une analyse historique, le CrUX BigQuery dataset permet de tracer l’evolution sur 12 mois et de correler les ameliorations de code avec les metriques reelles. Sur un site marchand qui a deploye AVIF en janvier, le LCP P75 est passe de 3,2 a 2,1 secondes en 6 semaines, visible directement dans le rapport BigQuery.

Une difference cruciale : Lighthouse simule un Moto G4 sur 4G ralentie. Si vos visiteurs sont majoritairement sur smartphones recents en 4G+ a Dakar ou Abidjan, leur experience reelle sera meilleure que le score Lighthouse. A l’inverse, si une partie du trafic est en 3G en zone semi-urbaine, le P75 CrUX sera moins bon que Lighthouse. Toujours croiser les deux sources avant de prioriser les optimisations.