Core Web Vitals : le guide pour optimiser vos performances
LCP, INP, CLS : maîtrisez les trois métriques que Google utilise pour évaluer l'expérience utilisateur de votre site. Un guide rédigé par des experts performance web pour passer au vert sur PageSpeed Insights.
Sommaire
Les fondamentaux
Pourquoi les Core Web Vitals comptent
Depuis juin 2021, Google intègre officiellement les Core Web Vitals dans ses facteurs de classement. Ce n'est pas un critère anecdotique : c'est un signal qui départage les sites à contenu équivalent. Si deux pages répondent aussi bien à une requête, celle qui offre la meilleure expérience utilisateur sera favorisée.
Les Core Web Vitals mesurent l'expérience réelle de vos visiteurs, pas un score théorique. Google collecte ces données via le Chrome User Experience Report (CrUX), une base de données agrégeant les métriques de performance de millions d'utilisateurs Chrome. Ce sont ces données terrain — et non les simulations de laboratoire — que Google utilise pour le classement.
L'impact business est mesurable. Selon les données publiées par Google, les sites respectant les seuils des Core Web Vitals constatent jusqu'à 24 % de conversions supplémentaires. La corrélation est directe : un site rapide et stable retient les visiteurs, réduit le taux de rebond et génère davantage de leads ou de ventes.
Vodafone a amélioré son LCP de 31 % et observé une hausse de 8 % de ses ventes. Yahoo! JAPAN a réduit son CLS de 98 % et vu son taux de rebond chuter de 15 %. Ces résultats ne sont pas des exceptions : ils illustrent ce qui se passe quand la performance devient une priorité technique.
Classement Google
Facteur de classement officiel depuis 2021
+24 % conversions
Impact mesuré sur les sites conformes
Données terrain
CrUX mesure les vrais utilisateurs
Métrique #1
LCP : Largest Contentful Paint
Le LCP mesure le temps nécessaire pour afficher le plus gros élément visible dans le viewport (la zone visible de l'écran). Cet élément est généralement l'image hero, une vidéo, ou le plus gros bloc de texte de la page. Le LCP reflète la perception de vitesse de chargement par l'utilisateur.
C'est la métrique la plus intuitive : quand un visiteur arrive sur votre page, combien de temps attend-il avant de voir le contenu principal ? Si ce délai dépasse 2,5 secondes, Google considère que l'expérience est dégradée. Au-delà de 4 secondes, c'est mauvais.
< 2,5s
Bon
Expérience fluide
2,5 - 4s
À améliorer
Risque de rebond
> 4s
Mauvais
53 % des visiteurs partent
Les éléments pris en compte par le LCP sont les balises <img>, <video>, les éléments avec une image de fond CSS background-image: url(), et les blocs de texte (paragraphes, titres). Le navigateur détermine automatiquement lequel est le plus grand en termes de surface visible.
Causes courantes d'un LCP lent
- •Images hero non optimisées (PNG/JPEG lourds au lieu de WebP/AVIF)
- •Temps de réponse serveur lent (TTFB élevé, absence de CDN)
- •CSS et JavaScript bloquant le rendu (render-blocking resources)
- •Web fonts bloquantes provoquant un écran blanc (FOIT)
- •Lazy loading appliqué par erreur à l'image LCP
Métrique #2
INP : Interaction to Next Paint
L'INP a officiellement remplacé le FID (First Input Delay) en mars 2024. Là où le FID ne mesurait que le délai de la première interaction, l'INP évalue la réactivité globale du site sur l'ensemble des interactions : clics, appuis sur des touches, taps sur mobile. C'est la pire latence observée (au 98e percentile) qui détermine le score final.
Concrètement, l'INP mesure le temps entre le moment où l'utilisateur interagit (clic sur un bouton, saisie dans un champ) et le moment où le navigateur affiche la réponse visuelle. Un site peut avoir un excellent FID (première interaction rapide) mais un INP catastrophique si les interactions suivantes sont lentes — typiquement après l'hydration React.
L'INP est la métrique la plus exigeante des trois Core Web Vitals. Selon les données CrUX, près de 65 % des sites mobiles échouent sur l'INP, contre environ 40 % pour le LCP. C'est le défi technique majeur de 2026.
< 200ms
Bon
Réponse perçue comme instantanée
200 - 500ms
À améliorer
Délai perceptible, friction
> 500ms
Mauvais
Interface ressentie comme figée
Les causes d'un INP élevé sont directement liées au JavaScript. Chaque interaction déclenche du code JavaScript côté client : si ce code est lourd, le thread principal est bloqué et le navigateur ne peut pas mettre à jour l'affichage. Les "long tasks" (tâches de plus de 50 ms) sont l'ennemi de l'INP.
L'hydration React est un cas typique : après le chargement du HTML serveur, React doit "hydrater" chaque composant côté client. Pendant cette phase, les interactions de l'utilisateur sont retardées. C'est pourquoi les React Server Components de Next.js sont une avancée majeure : ils éliminent l'hydration pour les composants qui n'en ont pas besoin.
Métrique #3
CLS : Cumulative Layout Shift
Le CLS mesure la stabilité visuelle de votre page. Chaque fois qu'un élément se déplace de façon inattendue après le rendu initial, un "layout shift" est enregistré. Le CLS est la somme de tous ces décalages non provoqués par l'utilisateur.
Vous avez déjà vécu cette frustration : vous êtes sur le point de cliquer sur un lien, et une image se charge soudainement au-dessus, poussant le contenu vers le bas. Vous cliquez alors sur le mauvais élément. C'est exactement ce que le CLS quantifie.
Contrairement au LCP et à l'INP qui sont exprimés en millisecondes, le CLS est un score sans unité. Il est calculé en multipliant la fraction de la fenêtre impactée par la distance du déplacement. Un score de 0 signifie une stabilité parfaite.
< 0,1
Bon
Mise en page stable
0,1 - 0,25
À améliorer
Décalages perceptibles
> 0,25
Mauvais
Expérience dégradée
Les causes les plus fréquentes de CLS élevé sont les images et vidéos sans dimensions explicites (attributs width/height), les publicités et embeds injectés dynamiquement, les web fonts provoquant un FOIT (Flash of Invisible Text) ou un FOUT (Flash of Unstyled Text), et le contenu injecté dynamiquement au-dessus du viewport (bandeaux cookies mal implémentés, bannières promotionnelles).
Toujours définir width et height
Spécifiez les dimensions de chaque image et vidéo dans le HTML. Le navigateur réserve ainsi l’espace avant le chargement. L’astuce CSS aspect-ratio permet également de réserver l’espace pour les conteneurs responsifs.
Réserver l’espace des embeds
Les iframes (YouTube, Google Maps, pubs) doivent avoir un conteneur avec des dimensions fixes ou un aspect-ratio défini. Sans cela, le contenu autour se décale quand l’embed se charge.
Utiliser font-display: swap
Cette propriété CSS affiche le texte avec une police de secours pendant le chargement de la web font, puis bascule. Cela évite le FOIT (texte invisible) tout en minimisant le décalage.
Préférer transform pour les animations
Les animations CSS utilisant top, left, width ou height provoquent des reflows et des layout shifts. Utilisez transform: translateX() / translateY() et opacity pour des animations fluides sans impact sur le CLS.
Diagnostic
Mesurer vos Core Web Vitals
Avant d'optimiser, il faut mesurer. Et en matière de Core Web Vitals, il existe deux types de données fondamentalement différents qu'il est crucial de distinguer.
Les données de laboratoire (lab data) sont générées par des outils comme Lighthouse ou Chrome DevTools dans un environnement contrôlé. Elles sont reproductibles et utiles pour le débogage, mais ne reflètent pas la réalité de vos utilisateurs.
Les données terrain (field data) proviennent de vrais utilisateurs via le CrUX. Elles sont collectées sur 28 jours glissants et reflètent l'expérience réelle avec des appareils, connexions et comportements variés. Ce sont les données terrain que Google utilise pour le classement.
Pour lire un rapport PageSpeed Insights, concentrez-vous d'abord sur la section "Découvrez l'expérience de vos utilisateurs" (données CrUX). Si votre site n'a pas assez de trafic pour apparaître dans le CrUX, fiez-vous aux données de labo en gardant à l'esprit qu'elles sont généralement plus optimistes que la réalité terrain.
Google PageSpeed Insights
Labo + TerrainL’outil de référence. Affiche les données CrUX (terrain) et un audit Lighthouse (labo). Score de 0 à 100 avec recommandations détaillées pour chaque métrique.
Google Search Console
TerrainRapport « Expérience sur la page » : vision globale de la conformité CWV de tout votre site, page par page, avec identification des URLs problématiques.
Chrome DevTools
LaboOnglet Performance : enregistrez une session de navigation et analysez chaque interaction, long task et layout shift. Idéal pour le débogage précis.
Lighthouse
LaboIntégré à Chrome DevTools ou utilisable en CLI. Génère un rapport complet avec scores Performance, Accessibilité, SEO et Bonnes Pratiques.
WebPageTest
Labo avancéTests depuis différents pays, appareils et connexions. Waterfall détaillé du chargement, filmstrip visuel et comparaison avant/après. Gratuit et extrêmement détaillé.
Extension Web Vitals (Chrome)
Terrain temps réelAffiche les CWV en temps réel pendant votre navigation. Permet de voir l’INP de chaque interaction et d’identifier immédiatement les éléments problématiques.
Besoin d'optimiser vos performances ?
Les outils identifient les problèmes. Un expert ONDEV les corrige et propulse vos Core Web Vitals au vert.
Demander un auditOptimisation
Optimiser le LCP en pratique
Le LCP est souvent la métrique la plus facile à améliorer car les causes sont bien identifiées et les solutions directes. Voici une checklist actionnable pour passer sous la barre des 2,5 secondes.
Optimiser les images (WebP/AVIF, responsive images)
Convertissez toutes vos images en WebP ou AVIF (gain de 25 à 50 % par rapport au JPEG). Utilisez l’attribut srcset pour servir la bonne taille selon l’écran. Le composant next/image fait tout cela automatiquement.
Précharger l’image LCP avec <link rel="preload">
Identifiez l’élément LCP de votre page (souvent l’image hero) et ajoutez un <link rel="preload" as="image"> dans le <head>. Cela indique au navigateur de télécharger l’image en priorité, avant même l’analyse du CSS.
Ne PAS lazy-loader l’élément LCP
Le lazy loading est excellent pour les images below-the-fold, mais il retarde le chargement de l’image LCP. Ajoutez loading="eager" (ou priority avec next/image) sur l’image hero pour qu’elle se charge immédiatement.
Réduire le TTFB (CDN, cache serveur, SSR)
Le Time To First Byte est le point de départ du LCP. Utilisez un CDN (Vercel Edge Network, Cloudflare), activez la mise en cache serveur et privilégiez le SSR ou SSG pour générer le HTML côté serveur plutôt que côté client.
Inliner le CSS critique (critical CSS)
Le CSS external bloque le rendu : le navigateur attend de l’avoir téléchargé avant d’afficher quoi que ce soit. Inlinez le CSS nécessaire au contenu above-the-fold dans le <head> et différez le reste.
Éliminer les web fonts bloquantes
Utilisez font-display: swap ou font-display: optional pour éviter que les polices ne bloquent le rendu. Préchargez les fichiers de police critiques avec <link rel="preload" as="font">. Next.js gère cela nativement via next/font.
Supprimer le JavaScript render-blocking
Déplacez les scripts non critiques en bas de page ou ajoutez defer/async. Éliminez les scripts tiers inutiles (chatbots, analytics redondants, widgets sociaux). Chaque script bloquant retarde le premier rendu.
Conseil ONDEV : commencez toujours par identifier votre élément LCP avec Chrome DevTools (onglet Performance > cochez "Web Vitals"). L'élément LCP est surligné en vert. Concentrez vos efforts sur cet élément spécifique plutôt que d'optimiser aveuglément toutes les images de la page.
Optimisation avancée
Optimiser INP et CLS
Optimiser l'INP
L'INP est un problème de JavaScript. Pour l'améliorer, il faut réduire le temps de blocage du thread principal. Chaque interaction qui prend plus de 200 ms à produire un rendu visuel dégrade votre score. Voici les techniques les plus efficaces.
Découper les long tasks (< 50 ms)
Utilisez setTimeout, requestAnimationFrame ou scheduler.yield() pour découper les tâches JavaScript longues en morceaux de moins de 50 ms. Cela libère le thread principal entre chaque morceau, permettant au navigateur de traiter les interactions en attente.
Utiliser requestIdleCallback et Web Workers
Déplacez les calculs non urgents (analytics, préchargement, formatage de données) dans requestIdleCallback pour qu’ils s’exécutent quand le navigateur est inactif. Pour les calculs lourds, utilisez des Web Workers qui s’exécutent dans un thread séparé.
Minimiser le JavaScript tiers
Chaque script tiers (chat, analytics, A/B testing, retargeting) ajoute du code au thread principal. Auditez chaque script avec Chrome DevTools > Performance et supprimez ceux dont le bénéfice ne justifie pas le coût. Privilégiez les alternatives légères.
Exploiter React 18+ : automatic batching et Suspense
React 18 regroupe automatiquement les mises à jour d’état (automatic batching), réduisant le nombre de re-renders. Suspense permet de différer le rendu des composants non critiques. startTransition marque les mises à jour lentes comme non urgentes.
Éviter l’hydration excessive
Avec Next.js App Router, utilisez les React Server Components par défaut. N’ajoutez "use client" que sur les composants qui nécessitent de l’interactivité. Moins il y a de composants hydratés, moins le thread principal est sollicité au chargement.
Optimiser le CLS
Le CLS est souvent le plus simple à corriger car les causes sont visuelles et les solutions prévisibles. L'objectif est d'empêcher tout déplacement inattendu du contenu.
Spécifier width et height sur toutes les images
Ajoutez systématiquement les attributs width et height (ou utilisez la propriété CSS aspect-ratio) sur chaque balise <img> et <video>. Le navigateur réserve l’espace exact avant le chargement du média.
Réserver l’espace pour les embeds et iframes
Enveloppez chaque iframe (YouTube, Google Maps, widget tiers) dans un conteneur avec un aspect-ratio fixe. Exemple : aspect-ratio: 16/9 pour les vidéos. Cela garantit que l’espace est réservé même avant le chargement de l’iframe.
Ne jamais injecter de contenu au-dessus du viewport
Les bannières promotionnelles, barres de notification ou bandeaux cookies qui s’insèrent en haut de page décalent tout le contenu vers le bas. Utilisez des overlays (position: fixed) ou réservez l’espace en permanence dans le layout.
Utiliser transform pour les animations
Les propriétés CSS top, left, width, height déclenchent des reflows (recalcul du layout). Utilisez transform: translate() et opacity qui sont gérées par le GPU sans impacter le layout. Le CLS ne compte pas les déplacements via transform.
Gérer les web fonts correctement
Utilisez font-display: swap avec des polices de secours de taille similaire (size-adjust en CSS). Ou mieux : préchargez vos fonts et utilisez font-display: optional pour éviter tout swap. Next.js gère cela nativement avec next/font.
Notre stack
Pourquoi Next.js excelle en performance
Chez ONDEV, nous développons exclusivement avec Next.js, le framework React de référence pour la production. Ce n'est pas un choix arbitraire : Next.js est conçu de A à Z pour la performance. Chaque fonctionnalité native contribue directement à l'amélioration des Core Web Vitals.
SSR et SSG : LCP ultra-rapide
Le Server-Side Rendering (SSR) et la Static Site Generation (SSG) génèrent le HTML côté serveur. Le navigateur reçoit du HTML prêt à afficher, sans attendre le téléchargement et l’exécution du JavaScript. Résultat : un LCP drastiquement amélioré par rapport au Client-Side Rendering.
next/image : optimisation automatique
Le composant next/image convertit automatiquement les images en WebP/AVIF, génère des tailles responsives via srcset, applique le lazy loading par défaut et force les dimensions (width/height). Tout cela sans configuration : le LCP et le CLS sont améliorés nativement.
next/font : zéro FOUT, zéro CLS
next/font télécharge les polices au build, les héberge en local et applique automatiquement size-adjust pour éviter tout décalage lors du swap. Plus besoin de Google Fonts externe ni de font-display: swap manuel.
Code splitting automatique
Next.js découpe automatiquement le JavaScript par route. Chaque page ne charge que le code dont elle a besoin. Aucun bundle monolithique de 500 Ko : le JavaScript envoyé au client est minimal, améliorant directement l’INP.
Route prefetching intelligent
Les liens visibles dans le viewport sont automatiquement préchargés en arrière-plan. Quand l’utilisateur clique, la page est déjà en mémoire. La navigation semble instantanée, le LCP de la page suivante est quasi nul.
React Server Components : moins de JS client
Avec l’App Router, les composants sont des Server Components par défaut. Leur code ne quitte jamais le serveur : zéro JavaScript envoyé au client pour ces composants. Moins de JS client = moins d’hydration = meilleur INP.
À titre de comparaison, un site WordPress classique repose sur du PHP sans SSR natif, accumule les plugins (chacun ajoutant son propre CSS et JavaScript), n'offre aucune optimisation d'image intégrée et nécessite des extensions tierces coûteuses pour atteindre des performances acceptables. Même avec ces extensions, les résultats restent en deçà d'un site Next.js natif.
Chaque site développé par ONDEV obtient systématiquement des scores verts sur les trois Core Web Vitals, sans compromis sur le design ni sur les fonctionnalités. La performance n'est pas une option, c'est le fondement technique de chaque projet.
FAQ
Questions fréquentes sur les Core Web Vitals
Prêt à accélérer votre site ?
Des Core Web Vitals au vert, un site rapide et stable, des visiteurs qui restent et convertissent. Parlons de votre projet.