Core Web Vitals : le guide complet pour les améliorer

Que sont les Core Web Vitals et pourquoi sont-ils importants

Les Core Web Vitals sont un ensemble de métriques que Google utilise pour mesurer l’expérience réelle de l’utilisateur sur une page web. Ce ne sont ni des métriques abstraites ni des métriques théoriques : elles reflètent la façon dont les personnes qui visitent réellement votre site le vivent.

Depuis 2021, Google les a intégrés comme facteur de classement. En 2026, avec la consolidation de l’INP (Interaction to Next Paint) comme métrique officielle depuis mars 2024, ces trois métriques sont plus déterminantes que jamais pour votre référencement naturel.

Les trois métriques actuelles sont :

• LCP (Largest Contentful Paint) : mesure la vitesse de chargement perçue. Le temps nécessaire pour afficher le plus grand élément visible à l’écran.
• INP (Interaction to Next Paint) : mesure la réactivité. Le temps que met la page à réagir visuellement à une interaction de l’utilisateur.
• CLS (Cumulative Layout Shift) : mesure la stabilité visuelle. Le nombre de décalages de mise en page inattendus pendant le chargement et l’utilisation de la page.

Selon les données du Chrome UX Report de fin 2025, seuls 42 % des sites web respectent simultanément les trois seuils des Core Web Vitals. Autrement dit, plus de la moitié des sites offrent une expérience sous-optimale et perdent potentiellement des positions à cause de cela.

Comment mesurer correctement les Core Web Vitals

Avant d’optimiser, il faut mesurer. Et il faut comprendre la différence entre deux types de données :

Données de terrain (Field Data)

Ce sont les mesures réelles des utilisateurs qui visitent votre site. Google les collecte via Chrome et les agrège dans le Chrome UX Report (CrUX). Ce sont ces données que Google utilise pour évaluer votre site dans le cadre du classement.

Elles sont évaluées au 75e percentile : votre score correspond à l’expérience de 75 % de vos utilisateurs. Si 75 % de vos visiteurs ont un LCP inférieur à 2,5 secondes, vous validez cette métrique.

Où les consulter :

• Google Search Console > Core Web Vitals : vue d’ensemble de toutes vos pages regroupées par statut.
• PageSpeed Insights : données de terrain pour des URL individuelles (si elles ont suffisamment de trafic).
• CrUX Dashboard (Looker Studio) : pour les analyses historiques et les tendances.

Données de laboratoire (Lab Data)

Ce sont des mesures simulées dans un environnement contrôlé. Elles ne reflètent pas l’expérience réelle de l’utilisateur, mais elles sont extrêmement utiles pour diagnostiquer des problèmes et vérifier des améliorations avant de les déployer.

Où les obtenir :

• Lighthouse (intégré aux Chrome DevTools).
• PageSpeed Insights (section laboratoire).
• WebPageTest (pour une analyse plus poussée avec la cascade réseau).

Important : une erreur fréquente consiste à optimiser uniquement pour les données de laboratoire en supposant que les données de terrain s’amélioreront automatiquement. Ce n’est pas toujours le cas. Les données de terrain dépendent des appareils, des connexions et des comportements réels de votre audience.

LCP : Largest Contentful Paint

Ce que c’est et comment ça fonctionne

Le LCP mesure le temps nécessaire pour afficher le plus grand élément de contenu visible dans le viewport (la partie visible de l’écran). Il peut s’agir d’une image, d’un bloc de texte, d’une vidéo ou d’un élément SVG.

Seuils :

• Bon : moins de 2,5 secondes.
• À améliorer : entre 2,5 et 4 secondes.
• Mauvais : plus de 4 secondes.

Les 4 causes principales d’un LCP lent

1. Temps de réponse du serveur trop long (TTFB)

Si votre serveur met plus de 600 millisecondes à répondre, il est pratiquement impossible d’obtenir un bon LCP. Les causes courantes : un hébergement mutualisé de faible qualité, des bases de données non optimisées et l’absence de cache.

Solutions :

• Migrez vers un hébergement plus performant ou utilisez un CDN comme Cloudflare.
• Mettez en place un cache côté serveur (Varnish, Redis, cache de page complète).
• Optimisez les requêtes vers la base de données et activez le cache d’objets.

2. Blocage du rendu par le CSS et le JavaScript

Le navigateur ne peut rien afficher tant qu’il n’a pas traité tous les fichiers CSS critiques. Si vous chargez des feuilles de style lourdes ou du JavaScript qui bloque le rendu, le LCP est retardé.

Solutions :

• Extrayez le CSS critique (above-the-fold) et intégrez-le directement dans le HTML.
• Chargez les fichiers CSS non critiques de manière asynchrone.
• Ajoutez defer ou async aux scripts qui ne sont pas essentiels au rendu initial.
• Supprimez le CSS et le JavaScript inutilisés. Sur de nombreux sites, plus de 50 % du CSS chargé n’est pas utilisé sur la page.

3. Chargement lent des ressources (images, polices)

Si l’élément LCP est une image (le cas le plus fréquent), vous devez vous assurer qu’elle se charge le plus tôt possible.

Solutions :

• Utilisez des formats modernes comme WebP ou AVIF. Ils peuvent réduire le poids de 30 à 50 % par rapport au JPEG.
• Ajoutez fetchpriority="high" sur l’image LCP pour indiquer au navigateur de la prioriser.
• Utilisez preload pour les ressources critiques : <link rel="preload" as="image" href="hero.webp">.
• N’appliquez pas loading="lazy" à l’image LCP. Le lazy loading est réservé aux images below-the-fold.
• Définissez toujours width et height sur les images pour que le navigateur réserve l’espace.

4. Rendu côté client

Les applications SPA (Single Page Applications) qui dépendent du JavaScript pour afficher le contenu initial ont souvent un mauvais LCP, car le navigateur doit télécharger, analyser et exécuter le JavaScript avant d’afficher quoi que ce soit.

Solutions :

• Utilisez le SSR (Server-Side Rendering) ou le SSG (Static Site Generation) pour générer le HTML côté serveur.
• Mettez en place une hydratation partielle pour réduire la quantité de JavaScript nécessaire au chargement initial.
• Des frameworks comme Astro, Next.js ou Nuxt offrent ces capacités nativement.

INP : Interaction to Next Paint

Ce que c’est et comment ça fonctionne

L’INP (Interaction to Next Paint) a officiellement remplacé le FID (First Input Delay) en mars 2024. Alors que le FID ne mesurait que la première interaction, l’INP évalue toutes les interactions de l’utilisateur pendant l’ensemble de la session et retient la latence la plus élevée (avec des ajustements statistiques pour écarter les valeurs aberrantes).

Une « interaction » comprend les clics, les appuis sur l’écran tactile et les frappes au clavier. Le défilement n’est pas considéré comme une interaction pour l’INP.

Seuils :

• Bon : moins de 200 millisecondes.
• À améliorer : entre 200 et 500 millisecondes.
• Mauvais : plus de 500 millisecondes.

Pourquoi l’INP est plus exigeant que le FID

Le FID ne mesurait que le délai avant que le navigateur commence à traiter l’interaction. L’INP mesure le cycle complet : du moment où l’utilisateur interagit jusqu’à ce que le navigateur affiche la mise à jour visuelle à l’écran. Cela comprend :

1. Input delay : le temps pendant lequel l’interaction attend dans la file parce que le thread principal est occupé.
2. Processing time : le temps d’exécution des gestionnaires d’événements (event handlers).
3. Presentation delay : le temps que met le navigateur à calculer la mise en page et à afficher la mise à jour visuelle.

D’après les données de web.dev, lors du passage du FID à l’INP, de nombreux sites qui validaient le FID ont échoué à l’INP. La raison : l’INP est une métrique bien plus représentative de l’expérience réelle de l’utilisateur.

Comment améliorer l’INP

1. Réduisez la charge du thread principal

Le JavaScript lourd est l’ennemi numéro un de l’INP. Chaque milliseconde pendant laquelle le thread principal exécute du JavaScript est une milliseconde d’attente pour l’utilisateur avant de voir la réponse à son interaction.

Solutions :

• Découpez les tâches longues (Long Tasks) en tâches plus courtes avec scheduler.yield() ou setTimeout.
• Supprimez les scripts tiers inutiles. Chaque widget, tracker ou chat que vous ajoutez entre en concurrence pour le thread principal.
• Utilisez des Web Workers pour déporter les calculs lourds hors du thread principal.

2. Optimisez les gestionnaires d’événements

Si le code exécuté lorsque l’utilisateur clique est lent, l’INP sera mauvais quel que soit le reste.

Solutions :

• Évitez les manipulations inutiles du DOM dans les gestionnaires d’événements.
• Utilisez requestAnimationFrame pour séparer la logique métier des mises à jour visuelles.
• Appliquez un debounce ou un throttle aux interactions fréquentes comme le scroll ou le resize.

3. Réduisez la taille du DOM

Un DOM trop volumineux ralentit toutes les opérations de mise en page et d’affichage. Google recommande de ne pas dépasser 1 400 nœuds dans le DOM.

Solutions :

• Mettez en place la virtualisation pour les longues listes (seuls les éléments visibles sont rendus).
• Simplifiez la structure HTML en supprimant les wrappers inutiles.
• Chargez les sections de contenu à la demande, lorsqu’elles deviennent pertinentes.

4. Réduisez l’impact des scripts tiers

Analytics, chats en direct, pixels de suivi, widgets de réseaux sociaux. Chaque script tiers que vous ajoutez à votre site a un coût en INP.

D’après mon expérience, 40 à 60 % du JavaScript exécuté par un site moyen provient de scripts tiers. Auditez tous les scripts que vous chargez et supprimez ceux qui n’apportent pas de valeur claire.

Solutions :

• Chargez les scripts non essentiels avec defer ou de façon dynamique après l’interaction de l’utilisateur.
• Utilisez des façades pour les widgets lourds : affichez une image statique du chat ou de la carte et ne chargez le vrai widget que lorsque l’utilisateur interagit.
• Instaurez une politique de « budget JavaScript » : définissez une limite maximale de Ko de JS et ne la dépassez pas.

CLS : Cumulative Layout Shift

Ce que c’est et comment ça fonctionne

Le CLS mesure à quel point le contenu visible de la page se déplace de façon inattendue. Ces moments où vous lisez un article et où le texte saute soudain parce qu’une image s’est chargée plus haut, ou où vous êtes sur le point de cliquer sur un bouton et qu’une bannière apparaît et décale tout.

Seuils :

• Bon : moins de 0,1.
• À améliorer : entre 0,1 et 0,25.
• Mauvais : plus de 0,25.

Le CLS se calcule en multipliant la fraction d’impact (quel pourcentage du viewport se déplace) par la fraction de distance (de combien il se déplace). Une valeur de 0 signifie qu’il n’y a aucun mouvement inattendu.

Les causes les plus fréquentes d’un CLS élevé

1. Images et vidéos sans dimensions définies

C’est l’erreur la plus fréquente et la plus facile à corriger. Si vous ne définissez pas width et height sur vos éléments <img> et <video>, le navigateur ne peut pas réserver l’espace avant de charger la ressource.

Solution : définissez toujours les dimensions de vos images. Avec le CSS moderne, vous pouvez utiliser aspect-ratio pour conserver les proportions sans fixer de tailles :

img {
  width: 100%;
  height: auto;
  aspect-ratio: 16 / 9;
}

2. Publicités, embeds et contenu injecté dynamiquement

Les bannières publicitaires sont l’une des principales causes de CLS sur le web. Elles se chargent après le contenu principal et poussent tout le reste vers le bas.

Solution : réservez un espace fixe pour les blocs publicitaires à l’aide de conteneurs dotés d’une hauteur minimale définie. Si vous ne connaissez pas la hauteur exacte, utilisez comme minimum la dimension publicitaire la plus fréquente.

3. Polices web qui provoquent un FOUT (Flash of Unstyled Text)

Lorsqu’une police web se charge et remplace la police système, elle peut provoquer un décalage de mise en page si les deux polices ont des métriques différentes.

Solutions :

• Utilisez font-display: optional pour éviter complètement le FOUT (la police web n’est utilisée que si elle est déjà en cache).
• Utilisez font-display: swap avec size-adjust pour que la police de secours ait les mêmes métriques que la police web.
• Préchargez les polices les plus importantes : <link rel="preload" as="font" href="font.woff2" crossorigin>.

4. Contenu injecté sans réservation d’espace

Bannières de cookies, barres de notification, éléments qui apparaissent de façon conditionnelle : ils peuvent décaler le contenu s’ils sont insérés dans le flux du document.

Solution : utilisez position: fixed ou position: sticky pour les éléments qui apparaissent dynamiquement, afin qu’ils ne poussent pas le reste du contenu. Les bannières de cookies, par exemple, devraient toujours être fixées en bas de l’écran.

Outils pour diagnostiquer et surveiller

Pour un diagnostic ponctuel

• Chrome DevTools > Performance : enregistrez une session de chargement et analysez précisément ce qui cause les problèmes. Vous voyez la chronologie des tâches du thread principal, les layout shifts et les événements LCP.
• Lighthouse : audit complet avec des recommandations spécifiques. Lancez-le en mode « Mobile » avec bridage (throttling) pour simuler des conditions réelles.
• WebPageTest : analyse plus poussée avec cascades réseau, filmstrip du chargement et comparaisons entre URL.

Pour une surveillance continue

• Google Search Console : rapport Core Web Vitals avec des données de terrain regroupées par statut. Le meilleur endroit pour avoir une vue d’ensemble.
• CrUX Dashboard : rapports historiques dans Looker Studio pour suivre les tendances dans le temps.
• Outils RUM (Real User Monitoring) : si vous avez besoin de données plus fines, des outils comme web-vitals.js permettent de collecter les métriques des utilisateurs réels et de les envoyer à votre outil d’analytics.

Plan d’action : bien prioriser

Lorsque les trois Core Web Vitals doivent être améliorés, il est important de prioriser. D’après mon expérience, voici l’ordre que je recommande :

Priorité 1 : CLS

C’est la métrique la plus rapide à améliorer dans la plupart des cas. Ajouter des dimensions aux images, réserver de l’espace pour les publicités et bien configurer les polices web sont des changements qui se mettent en place en quelques heures et ont un effet immédiat.

Priorité 2 : LCP

Les changements liés au LCP (optimisation des images, cache, preload) ont généralement un impact visible en 1 à 2 semaines, une fois que le CrUX a accumulé suffisamment de nouvelles données.

Priorité 3 : INP

C’est la métrique la plus complexe à améliorer, car elle exige généralement de refactoriser le JavaScript. Commencez par identifier les interactions les plus lentes avec les Chrome DevTools et traitez les tâches longues une par une.

Impact réel sur le SEO

Les Core Web Vitals sont un facteur de classement, mais il faut rester réaliste sur leur poids. Ce n’est pas le facteur le plus important. Le contenu pertinent, les backlinks et l’autorité du domaine pèsent toujours davantage sur la plupart des requêtes.

En revanche, en situation de concurrence serrée, les Core Web Vitals peuvent faire la différence. Si deux pages ont un contenu de qualité similaire et des profils de liens comparables, Google favorisera celle qui offre la meilleure expérience utilisateur.

Par ailleurs, les Core Web Vitals influencent indirectement d’autres métriques SEO. Un site rapide et stable présente :

• Un taux de rebond plus faible (les utilisateurs ne partent pas, agacés par la lenteur).
• Un temps passé sur le site plus long (ils consultent plus de pages et lisent plus de contenu).
• Un taux de conversion plus élevé (selon Google, chaque seconde gagnée sur le temps de chargement peut augmenter les conversions jusqu’à 27 %).

Améliorez l’expérience de votre site

Si vos Core Web Vitals sont au rouge ou à l’orange et que vous ne savez pas par où commencer, nous pouvons vous aider. Avec notre service de création et développement de sites web, nous construisons des sites optimisés pour la performance dès la base, et avec notre service SEO, nous veillons à ce que la partie technique de votre site ne freine pas votre référencement.

Demandez un conseil SEO gratuit et nous analyserons l’état actuel de vos Core Web Vitals avec un plan d’amélioration concret.