Core Web Vitals : le guide pratique pour améliorer tes performances

Les Core Web Vitals, tout le monde en parle. Peu de gens savent vraiment les optimiser.

Je vais être direct : les CWV ne vont pas propulser un contenu médiocre en position 1. Mais à contenu égal, un site rapide bat un site lent. Et en 2026, avec l’INP qui a remplacé le FID, les exigences ont monté d’un cran.

Voici comment diagnostiquer et corriger chaque métrique, avec des exemples concrets.

Les 3 métriques en bref

Métrique	Ce qu’elle mesure	Seuil “bon”
LCP (Largest Contentful Paint)	Vitesse d’affichage du contenu principal	< 2.5 secondes
INP (Interaction to Next Paint)	Réactivité aux interactions utilisateur	< 200 ms
CLS (Cumulative Layout Shift)	Stabilité visuelle de la page	< 0.1

Données labo vs données terrain

C’est la distinction la plus importante et la plus mal comprise.

Données labo (Lighthouse, PageSpeed local) : un test ponctuel, dans des conditions contrôlées. Utile pour diagnostiquer, mais pas représentatif de l’expérience réelle.

Données terrain (CrUX, rapport Search Console) : les vraies performances mesurées chez tes utilisateurs, sur leurs appareils, avec leur connexion. C’est ce que Google utilise pour le ranking.

Tu peux avoir un Lighthouse à 98 et des CWV terrain dans le rouge. C’est fréquent : Lighthouse teste sur un simulateur, tes utilisateurs sont sur un Android à 200€ avec de la 4G.

LCP : le temps d’affichage du contenu principal

Le LCP mesure le temps que met le plus grand élément visible à s’afficher. C’est souvent une image hero, un titre, ou un bloc de texte.

Les causes les plus fréquentes

1. Images non optimisées

C’est le coupable n°1. Une image hero de 2 Mo qui met 3 secondes à charger, c’est un LCP catastrophique.

Corrections :

<!-- Mauvais -->
<img src="hero.jpg">

<!-- Bon -->
<img 
  src="hero.webp" 
  width="1200" 
  height="600" 
  alt="Description"
  fetchpriority="high"
  decoding="async"
>

• WebP ou AVIF : 30 à 50% plus léger que le JPG
• Dimensions explicites : évite le reflow
• fetchpriority="high" : dit au navigateur de prioriser cette image
• Pas de lazy loading sur l’image LCP — erreur classique

2. Fonts qui bloquent le rendu

Les Google Fonts chargées de manière classique bloquent l’affichage du texte pendant 1 à 3 secondes.

<!-- Ajoute font-display: swap -->
<link href="https://fonts.googleapis.com/css2?family=Inter:wght@400;600&display=swap" rel="stylesheet">

<!-- Ou mieux : self-host tes fonts -->
<style>
  @font-face {
    font-family: 'Inter';
    src: url('/fonts/inter-400.woff2') format('woff2');
    font-weight: 400;
    font-display: swap;
  }
</style>

3. Rendu bloqué par le JavaScript

Un bundle JS de 500 Ko qui se charge avant le HTML visible, ça retarde tout. Solutions :

• defer ou async sur les scripts non critiques
• Code splitting : ne charge que le JS nécessaire pour la page courante
• Server-side rendering (SSR) ou Static Site Generation (SSG) — c’est pour ça que j’utilise Astro sur mes projets et que je le recommande à mes clients e-commerce quand c’est pertinent

4. TTFB lent (Time to First Byte)

Si ton serveur met 1.5 secondes à répondre, ton LCP ne sera jamais sous 2.5 secondes. Causes habituelles :

• Hébergement mutualisé saturé
• Pas de CDN
• Requêtes base de données non optimisées
• Pas de cache serveur

Un CDN type Cloudflare (gratuit) + un cache page résout 90% des problèmes de TTFB.

INP : la réactivité aux interactions

L’INP a remplacé le FID en mars 2024. C’est plus exigeant : le FID ne mesurait que le premier input. L’INP mesure TOUTES les interactions et prend la pire (au 75e percentile).

Ce qui tue ton INP

1. JavaScript lourd sur le main thread

Chaque fois qu’un script JS fait un calcul lourd, le navigateur ne peut pas répondre aux clics. Les coupables :

• Analytics et trackers (GTM avec 15 tags, Facebook Pixel, Hotjar…)
• Carousels et sliders JS
• Frameworks lourds (React côté client avec hydration)

2. Third-party scripts

Fais l’inventaire de tes scripts tiers. J’ai vu des sites avec 25 scripts third-party. Chacun ajoute du temps au main thread.

Pose-toi la question pour chacun : “est-ce que ce script vaut 10 ms d’INP en plus ?” Souvent la réponse est non.

3. Handlers d’événements lourds

Un clic sur un bouton de filtre qui recalcule et re-render toute la page côté client → INP explosé.

Solutions :

• Découpe les tâches longues avec requestIdleCallback ou scheduler.yield()
• Utilise content-visibility: auto pour le rendering hors écran
• Privilégie les interactions côté serveur (bonne vieille navigation) quand c’est possible

Comment diagnostiquer

// Dans la console, installe web-vitals
new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.name === 'INP') {
      console.log('INP:', entry.duration, entry.target);
    }
  }
}).observe({ type: 'event', buffered: true });

L’extension Web Vitals de Chrome te montre l’INP en temps réel avec l’élément responsable.

CLS : la stabilité visuelle

Le CLS mesure les décalages visuels inattendus. Tu connais l’expérience : tu t’apprêtes à cliquer sur un bouton, une image se charge au-dessus, tout se décale, et tu cliques sur une pub.

Les sources de CLS les plus courantes

1. Images et vidéos sans dimensions

<!-- Mauvais : le navigateur ne sait pas quelle taille réserver -->
<img src="photo.jpg">

<!-- Bon : le navigateur réserve l'espace -->
<img src="photo.jpg" width="800" height="600" alt="...">

<!-- Encore mieux avec CSS modern -->
<img src="photo.jpg" style="aspect-ratio: 4/3; width: 100%;" alt="...">

2. Publicités et embeds dynamiques

Les pubs qui se chargent après le contenu déplacent tout vers le bas. Solutions :

• Réserve un espace fixe pour chaque emplacement pub (min-height)
• Utilise contain-intrinsic-size pour les éléments lazy-loadés

3. Fonts qui changent de taille

Le flash FOUT (Flash of Unstyled Text) : le texte s’affiche en Arial, puis bascule en ta font custom avec une taille différente. Tout se décale.

Solution : ajuste la taille de ta font de fallback pour matcher ta font custom :

@font-face {
  font-family: 'MaFont';
  src: url('mafont.woff2') format('woff2');
  font-display: swap;
  /* Ajuste le fallback pour réduire le CLS */
  size-adjust: 105%;
  ascent-override: 90%;
  descent-override: 20%;
}

4. Contenu injecté dynamiquement

Bannière cookie, barre de notification, chat widget — tout ce qui s’insère dans le DOM après le chargement initial cause du CLS.

Mets-les en overlay (position fixed/sticky) plutôt qu’en flux.

Plan d’action par priorité

Semaine 1 : quick wins

• Compresser et convertir toutes les images en WebP
• Ajouter width/height sur toutes les images
• Mettre fetchpriority="high" sur l’image LCP
• Ajouter font-display: swap aux fonts

Semaine 2-3 : optimisations moyennes

• Auditer et réduire les scripts third-party
• Mettre en place un CDN si pas déjà fait
• Différer le chargement des scripts non critiques
• Réserver l’espace pour les pubs et embeds

Mois 2 : optimisations avancées

• Self-host les fonts critiques
• Implémenter le code splitting JS
• Optimiser les handlers d’interactions lourds
• Considérer SSR/SSG si le site est full client-side

L’impact SEO réel des CWV

Soyons honnêtes : les CWV sont un signal de ranking parmi des centaines. Un site lent avec un excellent contenu battra un site rapide avec du contenu médiocre.

Mais dans les SERP compétitives — e-commerce, assurance, voyage — où 10 sites ont un contenu équivalent, les CWV font la différence. J’ai vu des gains de 3 à 5 positions sur des requêtes concurrentielles après optimisation CWV.

Et surtout, des CWV corrects améliorent l’expérience utilisateur, ce qui impacte :

• Le taux de rebond (moins de gens partent)
• Le taux de conversion (les gens font ce que tu veux)
• Le temps passé (engagement plus long)

C’est un cercle vertueux. D’ailleurs, si tu veux comprendre comment Google évalue ton site dans sa globalité, mon guide sur l’audit SEO complet détaille la méthode.

Les outils indispensables

Outil	Usage
PageSpeed Insights	Données terrain + labo, recommandations
Search Console (rapport CWV)	Vue d’ensemble du site
Chrome DevTools (Performance)	Diagnostic détaillé page par page
Extension Web Vitals	Monitoring en temps réel pendant la navigation
WebPageTest	Tests avancés multi-localisations

FAQ

Les Core Web Vitals sont-ils un facteur de ranking important ?

C’est un facteur de départage, pas un facteur principal. Le contenu, les backlinks et la pertinence restent dominants. Mais dans les secteurs concurrentiels, les CWV peuvent te faire gagner (ou perdre) quelques positions cruciales.

Mon Lighthouse est à 95 mais mes CWV terrain sont mauvais, pourquoi ?

Lighthouse teste en conditions labo (connexion simulée, appareil puissant). Tes vrais utilisateurs ont des appareils moins performants et des connexions variables. C’est pour ça qu’il faut toujours regarder les données CrUX dans Search Console.

Combien de temps pour améliorer ses CWV ?

Les quick wins (images, fonts) montrent des résultats en quelques jours après mise en prod. Les optimisations JS/architecture prennent 2 à 4 semaines de développement. Les données terrain dans Search Console mettent 28 jours à se mettre à jour.

Faut-il un développeur pour optimiser les CWV ?

Pour les quick wins (images, fonts, lazy loading), un webmaster peut gérer. Pour les optimisations JS avancées, le code splitting, l’INP — oui, il faut un développeur. Si tu as besoin d’un diagnostic, c’est exactement ce que couvre mon audit SEO technique.

Les frameworks JavaScript (React, Vue) sont-ils mauvais pour les CWV ?

Pas intrinsèquement, mais ils ajoutent de la complexité. Un SPA React mal optimisé aura un mauvais LCP et un mauvais INP. La solution : SSR (Next.js, Nuxt), SSG (Astro, Gatsby), ou au minimum du code splitting agressif. Les frameworks légers (Astro, Svelte) ont un avantage naturel sur les CWV.