Upted
Référencement SEO

Core Web Vitals : comment optimiser LCP, INP et CLS en 2026

Guide technique pour optimiser les Core Web Vitals : LCP, INP et CLS. Outils de mesure, corrections concretes et exemples avant/apres pour ameliorer les performances.

Par Ted

Les Core Web Vitals : ce que Google mesure vraiment

Les Core Web Vitals (CWV) sont les trois metriques d’experience utilisateur que Google utilise comme facteur de classement. Depuis mars 2024, la metrique INP (Interaction to Next Paint) a remplace FID (First Input Delay). Ces metriques ne sont pas un concept abstrait : elles mesurent des experiences concretes que vivent vos visiteurs a chaque chargement de page.

Un site qui echoue sur les CWV ne sera pas penalise brutalement. Mais a contenu equivalent et backlinks equivalents, Google favorisera systematiquement le site qui offre une meilleure experience utilisateur. Sur des requetes competitives, cette difference fait basculer un site de la position 5 a la position 12.

LCP : Largest Contentful Paint

Ce que mesure le LCP

Le LCP mesure le temps necessaire pour afficher le plus grand element visible dans le viewport (la zone visible de l’ecran). Cet element est generalement une image hero, une video ou un bloc de texte principal.

Les seuils Google :

  • Bon : moins de 2,5 secondes
  • A ameliorer : entre 2,5 et 4 secondes
  • Mediocre : plus de 4 secondes

Les causes d’un mauvais LCP

  1. Temps de reponse serveur eleve (TTFB) : si le serveur met 1,5 seconde a repondre, le LCP ne peut pas etre bon. Le TTFB devrait etre inferieur a 800 ms.
  2. Images non optimisees : une image hero de 2 Mo en JPEG met plusieurs secondes a charger sur une connexion mobile 4G.
  3. CSS bloquant le rendu : le navigateur ne peut afficher aucun contenu tant que les fichiers CSS ne sont pas charges et parses.
  4. Chargement differe du contenu principal : si le contenu principal est injecte par JavaScript apres le chargement initial, le LCP explose.

Les corrections concretes

Optimiser les images :

  • Convertissez en WebP ou AVIF (reduction de 25 a 50 % par rapport au JPEG)
  • Dimensionnez les images a la taille d’affichage reelle. Une image de 3000x2000 pixels affichee a 600x400 est un gaspillage de bande passante.
  • Utilisez l’attribut srcset pour servir des tailles adaptees a chaque ecran
  • Pour l’image LCP (hero), ajoutez fetchpriority="high" et supprimez le loading="lazy" (le lazy loading retarde le LCP)

Reduire le TTFB :

  • Activez un CDN (Cloudflare gratuit suffit pour la plupart des sites)
  • Passez a PHP 8.2+ si votre site tourne sur WordPress/PrestaShop
  • Activez le cache serveur (cache opcode, cache de page)
  • Envisagez un hebergement plus performant si votre TTFB depasse 1 seconde

Debloquer le rendu CSS :

  • Inlinez le CSS critique (les styles necessaires au rendu du contenu visible) directement dans le <head>
  • Chargez le reste du CSS en asynchrone avec media="print" onload="this.media='all'"
  • Minifiez tous les fichiers CSS (WP Rocket, Autoptimize ou esbuild en build statique)

Exemple avant/apres : un site WordPress avec un hero image JPEG de 1,8 Mo et un TTFB de 1,2 seconde avait un LCP de 5,3 secondes sur mobile. Apres conversion en WebP (180 Ko), activation de Cloudflare et inlining du CSS critique, le LCP est passe a 1,9 seconde.

INP : Interaction to Next Paint

Ce que mesure l’INP

L’INP mesure la reactivite du site aux interactions utilisateur (clics, taps, saisie clavier). Il prend en compte le delai entre l’interaction et le moment ou le navigateur affiche la mise a jour visuelle. L’INP considere toutes les interactions pendant la session et retient la pire (ou la 98e percentile sur les sessions longues).

Les seuils Google :

  • Bon : moins de 200 ms
  • A ameliorer : entre 200 et 500 ms
  • Mediocre : plus de 500 ms

Les causes d’un mauvais INP

  1. JavaScript lourd sur le thread principal : des scripts tiers (analytics, chat widgets, A/B testing) qui monopolisent le processeur pendant que l’utilisateur essaie d’interagir.
  2. Gestionnaires d’evenements couteux : un click handler qui declenche un recalcul du DOM lourd (re-rendu d’un composant complexe, manipulation de listes longues).
  3. Hydratation des frameworks JS : les frameworks comme React ou Next.js executent une phase d’hydratation qui peut bloquer les interactions pendant plusieurs centaines de millisecondes.

Les corrections concretes

Reduire le JavaScript :

  • Identifiez les scripts les plus lourds avec Chrome DevTools > Performance > Bottom-Up. Cherchez les “Long Tasks” (taches de plus de 50 ms qui bloquent le thread principal).
  • Differez le chargement des scripts non essentiels avec defer ou async
  • Supprimez les scripts inutilises. Un site moyen charge 400 Ko de JavaScript dont 60 % n’est jamais execute sur la page courante.

Decouper les taches longues :

  • Utilisez requestIdleCallback ou scheduler.yield() pour fragmenter les calculs lourds en morceaux de moins de 50 ms
  • Pour React, utilisez useTransition et startTransition pour marquer les mises a jour non urgentes

Optimiser les interactions :

  • Utilisez content-visibility: auto en CSS pour eviter le rendu des elements hors ecran
  • Evitez les re-rendus inutiles des composants React avec React.memo et useMemo
  • Pour les listes longues, implementez la virtualisation (react-window, @tanstack/virtual)

Reduire l’impact des scripts tiers :

  • Chargez Google Analytics via le Google Tag Manager en mode differé
  • Remplacez les widgets de chat (Intercom, Drift) par des solutions plus legeres ou chargez-les apres l’interaction utilisateur
  • Differez les scripts A/B testing qui injectent du JS synchrone

CLS : Cumulative Layout Shift

Ce que mesure le CLS

Le CLS mesure la stabilite visuelle de la page. Chaque fois qu’un element visible se deplace de maniere inattendue (une image qui s’affiche et pousse le texte vers le bas, une banniere pub qui s’insere), un score de decalage est calcule. Le CLS est la somme des pires decalages pendant la duree de vie de la page.

Les seuils Google :

  • Bon : moins de 0,1
  • A ameliorer : entre 0,1 et 0,25
  • Mediocre : plus de 0,25

Les causes d’un mauvais CLS

  1. Images sans dimensions : si la largeur et la hauteur ne sont pas specifiees, le navigateur ne reserve pas d’espace. Quand l’image se charge, elle pousse tout le contenu.
  2. Polices web (FOUT) : le texte s’affiche d’abord avec une police systeme, puis “saute” quand la police web arrive.
  3. Contenu injecte dynamiquement : publicites, bannieres cookies, barres de notification qui s’inserent en haut de page apres le chargement initial.
  4. Iframes sans dimensions : les embeds YouTube, les cartes Google Maps sans width/height fixes.

Les corrections concretes

Images et videos :

  • Ajoutez les attributs width et height sur chaque balise <img> et <video>
  • Utilisez le CSS aspect-ratio pour les conteneurs responsives : 
    .hero-image {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
}

Polices :

  • Utilisez font-display: swap dans votre @font-face pour eviter le Flash of Invisible Text
  • Preloadez vos polices critiques : <link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>
  • Ajustez la police de fallback avec size-adjust pour minimiser le decalage lors du swap : 
    @font-face {
  font-family: 'Fallback';
  src: local('Arial');
  size-adjust: 105%;
  ascent-override: 90%;
}

Contenu dynamique :

  • Reservez un espace fixe pour les publicites et les bannieres avec min-height
  • Placez les bannieres cookies en bas de page (overlay) plutot qu’en haut (push)
  • Chargez les iframes avec des dimensions explicites

Exemple avant/apres : un site e-commerce avait un CLS de 0,38 a cause d’images produit sans dimensions et d’une banniere promo injectee en haut de page. Apres ajout des attributs width/height, passage au CSS aspect-ratio et deplacement de la banniere en overlay, le CLS est passe a 0,04.

Les outils de mesure

Donnees de laboratoire (Lab Data)

  • PageSpeed Insights : analyse une page et fournit les metriques simulees + les recommandations
  • Chrome DevTools > Performance : diagnostic detaille en local
  • Lighthouse (integre dans Chrome) : audit complet avec score Performance

Donnees de terrain (Field Data)

  • Google Search Console > Core Web Vitals : donnees reelles des 28 derniers jours, agreges par type de page
  • Chrome UX Report (CrUX) : donnees reelles accessibles via BigQuery ou l’API CrUX
  • web-vitals.js : librairie JavaScript de Google pour mesurer les CWV en production et les envoyer a votre outil d’analytics

Les donnees de terrain sont celles que Google utilise pour le classement. Les donnees de laboratoire sont utiles pour diagnostiquer et corriger, mais ne refletent pas forcement l’experience des vrais utilisateurs.

Integrer les CWV dans votre strategie SEO

Les Core Web Vitals ne sont pas un chantier isole. Ils s’inscrivent dans la strategie globale de referencement naturel : un site rapide et stable retient les visiteurs plus longtemps, reduit le taux de rebond et ameliore les taux de conversion. Les gains de performance se traduisent directement en gains business.

Upted integre l’optimisation des Core Web Vitals dans chaque accompagnement SEO technique. Si vos pages affichent des metriques en rouge dans Search Console, parlons-en pour identifier les corrections prioritaires et mesurer l’impact sur vos positions.

Core Web Vitals LCP INP CLS performance web

Besoin d'accompagnement ?

Discutons de votre projet. Premier audit offert pour les PME et agences en Ile-de-France.

Nous contacter