Core Web Vitals en 2026 : mesurer et améliorer LCP, INP et CLS

📚 Cet article fait partie de notre cluster SEO ouest-africain. Pour la méthode complète — recherche de mots-clés locaux, GBP, Schema, Core Web Vitals, mesure GA4 — voir le guide pilier SEO local au Sénégal et en Afrique de l’Ouest 2026.

Ce que sont les Core Web Vitals et pourquoi ils comptent pour votre référencement

Les Core Web Vitals sont un ensemble de trois métriques de performance web définies par Google pour évaluer l’expérience utilisateur d’une page. Depuis juin 2021, ces métriques font partie des signaux de classement de l’algorithme de recherche Google. En mars 2024, Google a remplacé le First Input Delay (FID) par l’Interaction to Next Paint (INP), rendant la mesure de la réactivité plus exigeante. Les trois métriques actuelles sont le Largest Contentful Paint (LCP), l’Interaction to Next Paint (INP) et le Cumulative Layout Shift (CLS).

Selon les données publiques du Chrome User Expérience Report (CrUX), seuls 42 % des sites web atteignent le seuil « bon » pour les trois métriques simultanément. Cela signifie que plus de la moitié des sites présente au moins un point faible en termes d’expérience utilisateur mesurable. C’est une opportunité directe pour le référencement : améliorer vos Core Web Vitals peut vous donner un avantage concret sur des concurrents qui les négligent.

LCP (Largest Contentful Paint) : le temps de chargement perçu

Le LCP mesure le temps nécessaire pour afficher le plus grand élément visible dans la fenêtre d’affichage. Cet élément est généralement une image hero, une vidéo ou un bloc de texte principal. Google considère qu’un LCP inférieur à 2,5 secondes est bon, entre 2,5 et 4 secondes nécessite une amélioration, et au-delà de 4 secondes est mauvais.

Les causes les plus fréquentes d’un LCP lent sont les images non optimisées, les polices web bloquantes et les temps de réponse serveur élevés. Pour diagnostiquer votre LCP, ouvrez les DevTools de Chrome, allez dans l’onglet Performance, enregistrez un chargement de page, et identifiez l’élément LCP dans le panneau de détails.

Optimiser le LCP concrètement

La première action est d’optimiser l’image LCP. Convertissez-la au format WebP ou AVIF (qui offrent une compression 25 à 50 % supérieure au JPEG), définissez des dimensions explicites avec les attributs width et height, et ajoutez l’attribut fetchpriority="high" pour indiquer au navigateur de la télécharger en priorité. Si l’image est servie depuis un CDN, assurez-vous que les en-têtes de cache sont correctement configurés.

La seconde action concerné le temps de réponse du serveur (TTFB). Un TTFB supérieur à 800 ms dégrade systématiquement le LCP. Les leviers d’amélioration incluent la mise en cache côté serveur (Redis, Memcached), l’utilisation d’un CDN pour rapprocher le contenu des utilisateurs, et l’optimisation des requêtes de base de données. Pour un site WordPress, un plugin de cache comme WP Rocket ou W3 Total Cache peut réduire le TTFB de 60 à 80 %.

INP (Interaction to Next Paint) : la réactivité aux interactions

L’INP a remplacé le FID en mars 2024. Contrairement au FID qui ne mesurait que le délai de la première interaction, l’INP mesure la latence de toutes les interactions de l’utilisateur (clics, appuis, saisies clavier) et retient la valeur la plus défavorable (approximativement le 98e percentile). Un INP inférieur à 200 ms est considéré bon, entre 200 et 500 ms nécessite une amélioration, et au-delà de 500 ms est mauvais.

L’INP est souvent la métrique la plus difficile à optimiser car elle dépend directement du JavaScript exécuté sur la page. Chaque fois qu’un utilisateur clique sur un bouton ou un lien, le navigateur doit exécuter le gestionnaire d’événements associé, mettre à jour le DOM et peindre le résultat à l’écran. Si le thread principal est occupé par un script long, l’interaction est retardée.

Stratégies pour améliorer l’INP

Identifiez d’abord les tâches longues (Long Tasks) avec l’API PerformanceObserver ou l’onglet Performance des DevTools. Toute tâche JavaScript durant plus de 50 ms est considérée longue et peut dégrader l’INP. Découpez ces tâches en morceaux plus petits en utilisant requestIdleCallback, setTimeout(fn, 0) ou la méthode scheduler.yield() disponible dans les navigateurs récents.

Réduisez ensuite la quantité de JavaScript chargé sur la page. Utilisez le panneau Coverage des DevTools Chrome pour identifier le code JavaScript non utilisé. Le chargement différé des scripts non critiques avec l’attribut defer ou le chargement dynamique via import() permet de libérer le thread principal pendant le chargement initial de la page.

CLS (Cumulative Layout Shift) : la stabilité visuelle

Le CLS mesure la somme des décalages de mise en page inattendus qui se produisent pendant toute la durée de vie de la page. Un décalage se produit lorsqu’un élément visible change de position sans action de l’utilisateur, par exemple quand une publicité se charge au-dessus du contenu que vous êtes en train de lire. Un CLS inférieur à 0,1 est bon, entre 0,1 et 0,25 nécessite une amélioration, et au-delà de 0,25 est mauvais.

Les causes les plus courantes de CLS élevé sont les images sans dimensions définies, les publicités et iframes sans espace réservé, les polices web qui provoquent un flash de texte invisible (FOIT) ou un flash de texte non stylé (FOUT), et le contenu injecté dynamiquement au-dessus du contenu existant.

Corriger les problèmes de CLS

Définissez toujours les attributs width et height sur vos images et vidéos, ou utilisez la propriété CSS aspect-ratio. Pour les publicités, réservez l’espace nécessaire avec un conteneur de taille fixe via CSS. Pour les polices, utilisez font-display: swap dans votre déclaration @font-face et préchargez les polices critiques avec <link rel="preload" as="font">.

Un piège courant concerné les bannières de consentement aux cookies : si elles poussent le contenu vers le bas au lieu de se superposer, elles génèrent un CLS significatif. Configurez votre bannière de cookies pour qu’elle apparaisse en overlay (position fixe) plutôt qu’insérée dans le flux du document.

Outils de mesure et suivi

Google propose plusieurs outils gratuits pour mesurer les Core Web Vitals. PageSpeed Insights (web.dev/measure) combine des données de laboratoire (Lighthouse) et des données terrain (CrUX). La Google Search Console affiche un rapport dédié dans la section « Expérience » qui identifie les URLs problématiques regroupées par type de problème.

Pour un suivi continu, l’API CrUX accessible via BigQuery permet d’analyser les tendances historiques de vos métriques. Des outils tiers comme SpeedCurve, Calibre ou DebugBear offrent un monitoring automatisé avec des alertes en cas de régression. L’investissement dans le suivi des Core Web Vitals se justifie directement par son impact sur le référencement et l’expérience utilisateur.

Étape 1 : poser le contexte Core Web Vitals 2026 sur votre site

Avant d’ouvrir un seul outil, posez-vous la bonne question : pourquoi vos visiteurs à Dakar, Abidjan ou Cotonou patientent devant votre page ? La réponse passe par trois métriques officielles que Google considère en 2026 : LCP (Largest Contentful Paint, vitesse d’affichage du plus gros élément), INP (Interaction to Next Paint, réactivité à chaque clic ou tap) et CLS (Cumulative Layout Shift, stabilité visuelle pendant le chargement). INP a remplacé FID début 2024, donc tout tutoriel antérieur qui parle encore de FID doit être ignoré. Sur la majorité des sites de PME ouest-africaines que nous mesurons, l’enjeu n’est pas la 4G urbaine — c’est la 3G périphérique et les téléphones d’entrée de gamme qui font exploser INP.

Concrètement, vous allez réaliser un audit en deux passes : une passe synthétique (Lighthouse, PageSpeed Insights) qui donne un score à un instant T en laboratoire, puis une passe terrain (CrUX, RUM web-vitals.js) qui montre ce que vivent réellement vos utilisateurs. Les deux passes ne donnent jamais le même chiffre, et c’est normal. Notez vos valeurs cibles : LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1, sur le 75e percentile. Tant qu’une seule métrique dépasse, la page n’est pas « Good » pour Google.

Étape 2 : mesurer en laboratoire avec Lighthouse et PageSpeed Insights

Ouvrez Chrome sur votre poste de travail, naviguez vers la page la plus consultée de votre site (souvent la page d’accueil ou une fiche produit). Pressez F12 pour ouvrir DevTools, puis l’onglet Lighthouse. Cochez « Performance », choisissez « Mobile » en device et « Slow 4G » en throttling, puis cliquez « Analyze page load ». L’analyse dure 30 à 60 secondes selon votre machine.

# Variante en ligne de commande, utile pour scripter sur un VPS Hostinger ou OVH
npx lighthouse https://votresite.sn --preset=mobile --throttling-method=simulate --output=html --output-path=./report.html

Le rapport HTML généré s’ouvre directement dans le navigateur et contient un onglet « Diagnostics » qui pointe les ressources lentes : CSS bloquants, JavaScript non utilisé, images surdimensionnées, polices web mal chargées. C’est le signal de réussite : si vous voyez ces sections remplies, vous savez par où commencer.

Étape 3 : capter les données terrain avec CrUX et web-vitals.js

Lighthouse ne montre qu’un chargement, depuis votre machine. Pour voir ce que vivent vos vrais visiteurs — par exemple un client à Thiès sur un Tecno Spark — installez la librairie web-vitals dans votre HTML. Insérez ce snippet juste avant la fermeture du </body> :

<script type="module">
  import {onLCP, onINP, onCLS} from 'https://unpkg.com/web-vitals@4?module';
  const send = m => navigator.sendBeacon('/rum', JSON.stringify(m));
  onLCP(send); onINP(send); onCLS(send);
</script>

Côté serveur, créez un endpoint /rum qui logge chaque envoi dans une table SQLite ou un fichier JSONL. Au bout de sept jours vous aurez une distribution réelle, segmentée par device et par pays, qui pèse beaucoup plus que n’importe quel score Lighthouse.

Étape 4 : optimiser le LCP de la page

Le LCP est presque toujours une grande image (hero, photo de produit) ou un bloc de texte avec une police custom. Première action : ajoutez l’attribut fetchpriority="high" et loading="eager" sur l’image hero, et un <link rel="preload" as="image"> dans le <head>. Servez les images en AVIF ou WebP avec un fallback JPEG via <picture>.

<link rel="preload" as="image" href="/img/hero.avif" fetchpriority="high">
<picture>
  <source srcset="/img/hero.avif" type="image/avif">
  <source srcset="/img/hero.webp" type="image/webp">
  <img src="/img/hero.jpg" alt="Boutique en ligne Dakar" width="1200" height="600" fetchpriority="high">
</picture>

Vous devriez voir le LCP chuter de 30 à 50 % sur un site qui ne faisait rien de tout cela. Re-mesurez via Lighthouse pour valider.

Étape 5 : améliorer l’INP en cassant les longues tâches JS

L’INP mesure la latence entre une interaction (clic, tap, frappe) et le rendu de la frame suivante. La cause numéro un sur les sites WordPress africains que nous auditons : des plugins qui exécutent du JavaScript lourd au moindre clic. Repérez-les via DevTools > Performance > Record > cliquez sur un bouton lent, puis cherchez les « long tasks » (barres rouges > 50 ms).

// Découper une tâche lourde avec scheduler.yield (Chrome 129+)
async function processItems(items) {
  for (const item of items) {
    doWork(item);
    if (navigator.scheduling?.isInputPending()) {
      await scheduler.yield();
    }
  }
}

Si scheduler.yield n’est pas disponible, fallback sur setTimeout(fn, 0). Vous saurez que c’est gagné quand votre INP sur le 75e percentile passe sous 200 ms dans CrUX.

Étape 6 : éliminer les sauts de mise en page (CLS)

Le CLS pénalise les bandeaux pub qui s’insèrent après coup, les images sans dimensions, et les polices web qui basculent du fallback à la police custom (FOIT/FOUT). Réservez systématiquement la place : ajoutez width et height sur chaque <img>, utilisez aspect-ratio en CSS pour les iframes YouTube, et chargez les polices avec font-display: swap + size-adjust.

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter.woff2') format('woff2');
  font-display: swap;
  size-adjust: 100.06%;
  ascent-override: 90%;
}

Vérifiez dans DevTools > Rendering > « Layout Shift Regions » : aucune zone bleue ne doit clignoter pendant le chargement.

Étape 7 : intégrer la mesure continue à votre workflow

Une optimisation ponctuelle se dégrade en quelques semaines (nouveau plugin, image non optimisée poussée par un rédacteur). Mettez en place un check hebdomadaire automatique : un job GitHub Actions qui lance Lighthouse CI sur cinq URLs critiques et qui vous alerte sur Slack ou WhatsApp si un budget est dépassé. Pour un site WooCommerce avec paiement Wave ou Mixx by Yas, surveillez tout particulièrement la page panier et la page checkout — ce sont elles qui convertissent.

# Workflow GitHub Actions minimal
name: lighthouse
on: [schedule, workflow_dispatch]
jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: treosh/lighthouse-ci-action@v12
        with:
          urls: |
            https://votresite.sn/
            https://votresite.sn/boutique/
            https://votresite.sn/panier/
          uploadArtifacts: true

Au bout de quatre semaines, vous aurez une courbe de tendance. Si LCP grimpe le mardi, c’est probablement votre déploiement hebdomadaire qui ajoute du JS — vous saurez où chercher.

Étape 8 : prioriser les pages qui rapportent (et pas toutes)

Vouloir un score 100 partout est une perte d’énergie. Sortez votre Google Search Console, exportez les requêtes des 28 derniers jours, identifiez les 10 pages qui génèrent 80 % du trafic. Concentrez l’optimisation sur ces 10 pages d’abord. Pour une plateforme e-commerce locale typique (5 000 visites/mois, panier moyen 35 000 FCFA soit environ 53,36 EUR au taux fixe 1 EUR = 655,957 FCFA), gagner 1 seconde de LCP sur la fiche produit augmente le taux de conversion de 7 à 10 % d’après les benchmarks Akamai.

Une fois ces pages stabilisées, élargissez aux pages catégorie, puis aux articles de blog. Ne touchez pas aux pages légales (mentions, CGU) tant que tout le reste n’est pas vert. Sur le même thème sur l’audit SEO global qui s’imbrique avec la performance, consultez notre tutoriel sur l’audit SEO complet d’un site WordPress, et pour la dimension serveur la configuration cache LiteSpeed/Redis sur un VPS abordable.