Core Web Vitals 2026 : optimiser LCP, INP et CLS pour Google

01 Qu'est-ce que les Core Web Vitals et pourquoi ça compte ?

Les Core Web Vitals (CWV) sont un ensemble de métriques défini par Google pour mesurer objectivement l'expérience utilisateur réelle sur une page web. Ils font partie du programme plus large Web Vitals, mais ce sont les trois métriques "core" qui sont intégrées comme signaux de classement depuis la Page Experience Update de juin 2021.

En mars 2024, Google a remplacé le FID (First Input Delay) par l'INP (Interaction to Next Paint), jugé beaucoup plus représentatif de la réactivité réelle d'une page. Cette transition est importante : si vous avez des guides ou des audits basés sur FID, il est temps de les mettre à jour.

02 Comment mesurer ses Core Web Vitals : terrain vs laboratoire

Il existe deux types de données CWV et la distinction est fondamentale : seules les données terrain comptent pour le classement Google.

Données terrain (field data) : celles qui comptent pour Google

Google collecte les données terrain via le Chrome User Experience Report (CrUX), alimenté par les vrais utilisateurs de Chrome. Ces données reflètent les conditions réelles : appareils variés, connexions mobiles, scripts tiers actifs. C'est ce que Google Search Console affiche dans le rapport Expérience de la page.

Données de laboratoire (lab data) : pour le débogage

PageSpeed Insights, Lighthouse et Chrome DevTools simulent un chargement dans des conditions contrôlées. Utiles pour identifier et reproduire les problèmes, mais non représentatifs des conditions réelles. Un score PSI de 95 ne garantit pas de bons CWV terrain.

03 LCP (Largest Contentful Paint) : la vitesse perçue de votre page

Le LCP mesure le temps entre le début du chargement et l'affichage du plus grand élément visible dans la fenêtre. Concrètement, c'est ce que l'utilisateur perçoit comme "la page est chargée". Il s'agit presque toujours d'une image hero, d'un bloc de texte principal ou d'une vidéo en autoplay.

Ce que Google identifie comme élément LCP

• Images (<img>, <image> en SVG)
• Images en background CSS si elles sont la plus grande zone visible
• Blocs de texte volumineux (paragraphe, titre H1)
• Vidéos (image de poster prise en compte)
• Les éléments <video> sans poster image sont souvent ignorés
• Les éléments <iframe> ne sont pas pris en compte

Pour identifier votre élément LCP : ouvrez Chrome DevTools → onglet Performance → enregistrez un rechargement → cherchez le marqueur LCP dans la timeline. L'élément sera mis en surbrillance dans le DOM.

04 INP (Interaction to Next Paint) : la réactivité de bout en bout

L'INP mesure le délai entre une interaction utilisateur (clic, frappe, tap) et le prochain affichage visible (next paint) qui en découle. Contrairement au FID qui ne mesurait que le premier événement, l'INP évalue toutes les interactions pendant la session et retient la plus longue (au 98e centile pour filtrer les valeurs aberrantes).

Décomposer une interaction lente

Une interaction lente se décompose en trois phases que Chrome DevTools peut vous révéler :

05 CLS (Cumulative Layout Shift) : la stabilité de votre mise en page

Le CLS quantifie les décalages de mise en page inattendus pendant le chargement. Quand un bouton se déplace juste au moment où l'utilisateur allait cliquer, c'est du CLS. C'est une expérience frustrante qui nuit à la crédibilité d'un site autant qu'à son SEO.

Le score CLS est calculé en multipliant la fraction d'impact (part de la fenêtre affectée) par la fraction de distance (distance de déplacement relative à la hauteur de la fenêtre). Un CLS de 0,1 signifie que 10% de la surface visible est instable.

Les causes les plus fréquentes de CLS élevé

• Images sans attributs width et height définis en HTML
• Publicités, embeds et iframes sans dimensions réservées
• Contenu injecté dynamiquement au-dessus du contenu existant
• Polices web qui provoquent un FOUT (Flash of Unstyled Text)
• Animations qui déclenchent layout (éviter top, left, width, height)
• Les bandeaux cookies injectés en haut de page sont une cause fréquente

06 Optimiser le LCP : les techniques qui font la différence

Le LCP est généralement le plus impactant à optimiser car il détermine la vitesse perçue du chargement. Les gains peuvent être spectaculaires avec les bonnes techniques.

1. Prioriser le chargement de l'élément LCP

C'est souvent la technique avec le meilleur retour sur investissement. Si votre LCP est une image, ajoutez l'attribut fetchpriority="high" et supprimez le loading="lazy" sur cette image uniquement.

<!-- Image LCP : haute priorité, pas de lazy load -->
<img
  src="/hero.webp"
  alt="Description de l'image hero"
  width="1200"
  height="630"
  fetchpriority="high"
  decoding="async"
/>

<!-- Toutes les autres images : lazy load -->
<img
  src="/autre-image.webp"
  alt="..."
  width="800"
  height="450"
  loading="lazy"
/>

2. Précharger les ressources critiques

<!-- Précharger l'image LCP (si en CSS background) -->
<link rel="preload" as="image"
      href="/hero.webp"
      fetchpriority="high"/>

<!-- Précharger les polices web critiques -->
<link rel="preload" as="font"
      href="/fonts/mafonte.woff2"
      type="font/woff2"
      crossorigin="anonymous"/>

<!-- Préconnexion aux domaines tiers critiques -->
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin/>

3. Optimiser les images

• Convertir en WebP (30% plus léger que JPG) ou AVIF (50% plus léger que JPG)
• Utiliser srcset pour servir la bonne taille selon l'écran
• Compresser avec Squoosh, Sharp ou ImageOptim avant upload
• Activer la compression Brotli ou gzip sur le serveur pour les ressources texte
• Utiliser un CDN pour les assets statiques

<!-- Image responsive avec formats modernes -->
<picture>
  <source
    type="image/avif"
    srcset="/hero-480.avif 480w, /hero-960.avif 960w, /hero-1200.avif 1200w"
    sizes="(max-width: 600px) 480px, (max-width: 1024px) 960px, 1200px"
  />
  <source
    type="image/webp"
    srcset="/hero-480.webp 480w, /hero-960.webp 960w, /hero-1200.webp 1200w"
    sizes="(max-width: 600px) 480px, (max-width: 1024px) 960px, 1200px"
  />
  <img src="/hero-1200.jpg" alt="Hero"
       width="1200" height="630"
       fetchpriority="high"/>
</picture>

4. Réduire le Time to First Byte (TTFB)

Un TTFB élevé (temps avant la première réponse du serveur) pénalise directement le LCP. Cibles : TTFB inférieur à 800ms. Leviers :

• Activer le cache HTTP (headers Cache-Control et ETag)
• Passer à un hébergement plus proche de vos utilisateurs (CDN edge)
• Utiliser HTTP/2 ou HTTP/3 si ce n'est pas encore le cas
• Optimiser les requêtes base de données pour les pages dynamiques

07 Optimiser l'INP : réduire la latence des interactions

L'INP est la métrique la plus difficile à optimiser car elle implique du JavaScript. La majorité des problèmes d'INP viennent de long tasks : des tâches JS qui s'exécutent pendant plus de 50ms et bloquent le thread principal, empêchant le navigateur de répondre aux interactions.

Identifier les long tasks dans DevTools

Ouvrez Chrome DevTools → onglet Performance → cliquez sur Record → interagissez avec la page → arrêtez. Les blocs rouges dans la timeline "Main" sont vos long tasks. Cliquez dessus pour voir quelle fonction JS est responsable.

Les optimisations JavaScript qui améliorent l'INP

• Découper les long tasks avec scheduler.yield() ou setTimeout(fn, 0) pour rendre la main au navigateur
• Charger les scripts non critiques avec defer ou async et les déplacer en fin de <body>
• Supprimer ou remplacer les scripts tiers lourds (chat widgets, analytics redondants, anciens polyfills)
• Utiliser requestIdleCallback pour les tâches non urgentes (analytics, tracking)
• Éviter les event listeners non debounced sur scroll et resize
• Les frameworks SPA (React, Vue, Angular) génèrent souvent de l'INP élevé lors des re-renders : profiler avec le React DevTools Profiler

// ❌ Long task bloquante : 200ms de traitement synchrone
button.addEventListener('click', () => {
  processHeavyData(); // bloque le thread 200ms
  updateUI();
});

// ✅ Découper avec scheduler.yield() (Chrome 115+)
button.addEventListener('click', async () => {
  updateUIImmediately(); // réponse visuelle rapide
  await scheduler.yield(); // rend la main au navigateur
  processHeavyData(); // traitement en tâche de fond
});

// ✅ Fallback compatible tous navigateurs
button.addEventListener('click', async () => {
  updateUIImmediately();
  await new Promise(resolve => setTimeout(resolve, 0));
  processHeavyData();
});

Auditer les scripts tiers

Les scripts tiers (Google Tag Manager, Facebook Pixel, Intercom, HotJar, etc.) sont souvent les premiers coupables d'un INP dégradé. Chaque script tiers ajoute ses propres event listeners et tâches JS.

• Charger GTM en defer et après le premier rendu
• Remplacer les chat widgets par des solutions allégées ou les charger au premier scroll
• Utiliser une façade pour les embeds lourds (YouTube, Vimeo)
• Auditer régulièrement avec WebPageTest (section "Third Party Summary")

08 Optimiser le CLS : stabiliser la mise en page

Le CLS est souvent le plus simple à corriger car les solutions sont souvent purement CSS ou HTML, sans refactoring JavaScript. La clé : réserver de l'espace pour chaque élément avant qu'il soit chargé.

Dimensions d'images : la règle absolue

Chaque image doit avoir des attributs width et height dans le HTML. Le navigateur peut alors calculer le ratio et réserver l'espace exact avant le chargement de l'image.

<!-- ✅ Image avec dimensions : zéro CLS -->
<img src="/photo.webp" alt="..."
     width="800" height="450"/>

/* CSS pour garder l'image responsive malgré les dimensions fixes */
img {
  max-width: 100%;
  height: auto; /* respecte le ratio width/height du HTML */
}

/* ✅ Réserver l'espace pour une pub ou un embed */
.ad-container {
  min-height: 250px; /* taille minimum connue */
  aspect-ratio: 4 / 1;
}

/* ✅ Skeleton loader pour contenu dynamique */
.skeleton {
  background: linear-gradient(90deg, #1e1e38 25%, #2a2a48 50%, #1e1e38 75%);
  background-size: 200% 100%;
  animation: skeleton-wave 1.5s infinite;
}
@keyframes skeleton-wave {
  0% { background-position: 200% 0; }
  100% { background-position: -200% 0; }
}

Polices web et FOUT

Quand une police web se substitue à la police système, le texte peut se redimensionner et provoquer du CLS. Solutions :

• Ajouter font-display: optional pour éviter tout FOUT (la police web n'est utilisée que si disponible instantanément)
• Utiliser font-display: swap + propriété CSS size-adjust pour ajuster le ratio de la police de remplacement
• Auto-héberger les polices pour éviter la latence DNS tierce
• Précharger les polices avec <link rel="preload">

/* Technique : ajuster la police fallback pour réduire le shift */
@font-face {
  font-family: 'MaPolice';
  src: url('/fonts/mapolice.woff2') format('woff2');
  font-display: swap;
  size-adjust: 105%;      /* ajuste la fallback pour matcher */
  ascent-override: 90%;   /* réduit la hauteur de ligne apparente */
}

/* Pour les animations : préférer transform et opacity
   qui ne déclenchent pas de layout */
.animated {
  transform: translateY(20px); /* ✅ pas de CLS */
  opacity: 0;
  /* éviter : top, left, margin, padding, width, height */
}

09 Impact réel des Core Web Vitals sur le classement Google

La question que tout le monde se pose : combien de positions peut-on gagner en améliorant ses CWV ? La réponse est nuancée, et il est important de ne pas survendre leur impact.

Ce que Google dit officiellement

Les CWV font partie des signaux d'expérience de la page qui incluent aussi HTTPS, mobile-friendliness et absence de pop-ups intrusives. Google précise que ces signaux n'entrent en jeu qu'à qualité de contenu équivalente entre deux pages concurrentes. Un contenu de référence sur un site lent battra toujours un contenu médiocre sur un site rapide.

Ce que les études terrain montrent

10 Checklist d'action prioritaire : par où commencer ?

Voici les actions classées par rapport impact/effort, à appliquer dans cet ordre. Les 5 premières peuvent être faites en une demi-journée sans toucher au backend.

Actions rapides (impact élevé, effort faible)

• Ajouter width et height sur toutes les images du site → élimine une grande partie du CLS
• Ajouter fetchpriority="high" sur l'image hero et supprimer son loading="lazy" → améliore le LCP
• Ajouter loading="lazy" sur toutes les autres images → réduit la charge initiale
• Ajouter defer sur tous les scripts non critiques → améliore LCP et INP
• Convertir les images en WebP avec Squoosh (gratuit, en ligne) → réduit le LCP de 20 à 40%

Actions intermédiaires (impact élevé, effort moyen)

• Précharger les polices critiques avec <link rel="preload"> et passer à font-display: swap
• Réserver des espaces minimums pour les blocs publicitaires et les embeds tiers
• Auditer et nettoyer les scripts tiers dans GTM : supprimer tout ce qui n'est pas utilisé activement
• Activer la compression Brotli sur le serveur (nginx, Apache ou via Cloudflare)
• Mettre en place un CDN (Cloudflare gratuit suffit pour 80% des sites)

Actions avancées (impact variable, effort élevé)

• Implémenter scheduler.yield() dans les event handlers JS lourds pour réduire l'INP
• Migrer vers des formats AVIF pour un gain supplémentaire de 20% sur le LCP images
• Implémenter un service worker pour le précaching des assets critiques
• Profiler et découper les long tasks avec Chrome DevTools (nécessite de toucher au JS)