Ce que les Core Web Vitals vous coûtent en revenus

Les Core Web Vitals sont souvent abordés sous l'angle du SEO. Cette approche sous-estime leur impact réel : en tant que signal de positionnement, leur poids reste modéré — Google l'a confirmé, et une page plus lente mais apportant la réponse la plus pertinente surclassera toujours une page ultra-rapide au contenu médiocre.

Le véritable enjeu réside dans la conversion. Un internaute qui quitte votre site avant la fin du rendu affiche un taux de conversion nul, et aucun positionnement dans les moteurs de recherche ne compensera cette perte.

Voici ce que mesurent concrètement ces trois indicateurs, les véritables causes de mauvais scores et les optimisations prioritaires.

Les trois indicateurs clés

Largest Contentful Paint (LCP)

Le moment où le plus grand élément visible termine son affichage. Il s'agit généralement de l'image principale (hero), de la balise H1 ou d'un bloc de texte volumineux.

Bon : moins de 2,5 secondes
À améliorer : entre 2,5 et 4,0 secondes
Médiocre : plus de 4,0 secondes

Le LCP est le reflet le plus fidèle du moment où une page devient exploitable pour l'utilisateur. C'est le premier indicateur à traiter.

Cumulative Layout Shift (CLS)

La mesure des déplacements inattendus de contenu pendant le chargement. Une situation bien connue : vous vous apprêtez à cliquer sur un lien, une bannière s'insère au-dessus, la mise en page se décale et vous cliquez sur un autre élément par erreur.

Bon : inférieur à 0,1
Médiocre : supérieur à 0,25

Le CLS est souvent le plus économique à corriger, ses causes étant limitées et parfaitement identifiées.

Interaction to Next Paint (INP)

Le délai de réponse visuelle de la page après une interaction utilisateur. Entré en vigueur en mars 2024 en remplacement du First Input Delay (FID), il est plus exigeant : il analyse l'ensemble des interactions tout au long de la visite, et non plus seulement la première.

Bon : moins de 200 ms
Médiocre : plus de 500 ms

L'INP est presque exclusivement lié au JavaScript — le thread principal étant saturé, le navigateur ne peut pas réactualiser l'affichage.

Données de laboratoire versus données de terrain

Cette distinction suscite de nombreuses confusions qu'il convient de clarifier.

Les données de laboratoire (Lab data) correspondent à une simulation dans un environnement contrôlé — ce que fournit Lighthouse dans Chrome DevTools. Reproductibles et précieuses pour le débogage, elles ne sont pourtant pas celles que Google retient pour le classement.

Les données de terrain (Field data) proviennent du rapport d'expérience utilisateur Chrome (CrUX) : des mesures réelles issues d'utilisateurs réels de Chrome sur une période glissante de 28 jours. C'est cette mesure que Google prend en compte et qui s'affiche dans la Search Console.

Ces deux sources divergent fréquemment. Dans ce cas, les données de terrain font foi. Un site peut obtenir un score Lighthouse de 95 sur la machine puissante d'un développeur tout en échouant sur le terrain, car la majorité de ses visiteurs naviguent sur des smartphones Android d'entrée ou de milieu de gamme connectés à des réseaux mobiles encombrés.

En pratique : optimisez pour le terrain, débuguez en laboratoire. Gardez à l'esprit que les données de terrain ont un temps de latence — un correctif peut mettre jusqu'à 28 jours pour se refléter pleinement dans les statistiques.

Notre outil d'audit SEO gratuit analyse les deux volets via l'API officielle Google PageSpeed Insights, vous permettant d'identifier immédiatement les écarts pour votre domaine.

Les vraies causes d'un mauvais LCP

Par ordre de fréquence :

Les images non optimisées

L'élément déclencheur du LCP est une image sur la plupart des pages, et elle est presque toujours surdimensionnée.

Le cas classique : un JPEG de 700 Ko en résolution 3000px affiché dans un conteneur de 640px, chargé sans priorité de rendu et sans format moderne alternatif.

Le correctif :

<picture>
  <source srcset="/hero-640.avif 640w, /hero-1280.avif 1280w" type="image/avif" />
  <source srcset="/hero-640.webp 640w, /hero-1280.webp 1280w" type="image/webp" />
  <img src="/hero-640.jpg" alt="…"
       width="640" height="480"
       fetchpriority="high" decoding="async" />
</picture>

Quatre optimisations majeures interviennent ici. L'AVIF et le WebP réduisent le poids du fichier de 50 à 80 % par rapport au JPEG à qualité égale. L'attribut srcset délivre aux mobiles un fichier adapté à leur écran. Les attributs width et height réservent l'espace nécessaire, neutralisant aussi le CLS. Enfin, fetchpriority="high" signale au navigateur que cette image est prioritaire sur toutes les autres requêtes.

Ce dernier attribut offre régulièrement le meilleur gain de performance pour un coût d'implémentation nul.

Ne placez jamais loading="lazy" sur l'image responsable du LCP. Le lazy-loading retarde le téléchargement, ce qui dégrade directement l'élément sur lequel vous êtes évalué. Réservez le chargement différé aux éléments sous la ligne de flottaison ; chargez l'image principale immédiatement.

Les ressources bloquant le rendu

Chaque feuille de style déclarée dans le <head> bloque l'affichage tant qu'elle n'est pas téléchargée et analysée. Il en va de même pour les scripts synchrones.

L'erreur fréquente reste l'enchaînement de requêtes :

/* dans styles.css — crée une chaîne de dépendances */
@import url('https://fonts.googleapis.com/css2?family=…');

Le navigateur doit charger styles.css, l'analyser, découvrir la règle @import, télécharger le fichier CSS des polices, l'analyser, puis enfin récupérer les polices. Quatre allers-retours séquentiels avant le moindre affichage de texte.

Déclarez les feuilles de style de polices directement dans le <head> HTML, précédées d'un preconnect :

<link rel="preconnect" href="https://fonts.googleapis.com" />
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=…&display=swap" />

La directive display=swap est déterminante : elle affiche le texte instantanément avec une police de secours le temps que la police web soit opérationnelle, évitant l'effet de texte invisible (FOIT).

Le temps de réponse du serveur (TTFB)

Si le Time To First Byte dépasse 600 ms, l'ensemble de la chaîne est ralenti. Les causes sont classiques : absence de mise en cache, hébergement sous-dimensionné, requêtes SQL non optimisées à chaque chargement ou CDN mal configuré.

Pour un site vitrine ou marketing, la génération statique est la réponse adaptée. Dès lors qu'une page ne varie pas selon l'utilisateur, elle doit être servie depuis un fichier sur disque plutôt qu'assemblée à chaque requête.

Une surcharge de JavaScript

Un framework nécessitant 400 Ko de JavaScript pour afficher une simple page textuelle impose un coût disproportionné. Sur un smartphone Android classique, l'analyse et l'exécution d'un tel volume peuvent dépasser une seconde avant le moindre affichage utile.

Il ne s'agit pas de rejeter les frameworks, mais d'éviter le rendu côté client pour des contenus qui relèvent du HTML statique.

Les vraies causes d'un mauvais CLS

Trois facteurs expliquent la quasi-totalité des problèmes.

Images sans dimensions définies. Sans attributs width et height, le navigateur ne peut réserver l'espace requis, décalant tout le contenu lors de l'apparition de l'image. Renseignez toujours ces deux valeurs, accompagnées de height: auto en CSS pour préserver la réactivité.

Remplacement des polices web. La police de secours s'affiche, puis la police web se charge avec des proportions différentes, provoquant un réajustement du texte. Corrigez cela avec font-display: swap et la directive size-adjust sur la police de secours via @font-face.

Contenus injectés dynamiquement. Bandeaux de cookies, barres promotionnelles, encarts publicitaires ou widgets tiers insérés en haut de document repoussent l'ensemble du contenu vers le bas. Réservez l'espace à l'avance ou positionnez-les en superposition fixe (overlay).

Les vraies causes d'un mauvais INP

L'INP résulte d'une saturation du thread principal. Les sources courantes :

Tâches longues (Long Tasks) — toute tâche JavaScript dépassant 50 ms bloque la réactivité de l'interface
Gestionnaires d'événements trop lourds — traitements complexes exécutés directement lors d'un clic ou d'une saisie
Scripts tiers accumulés — outils de mesure d'audience, widgets de chat, heatmaps et outils de tests A/B mobilisant le processeur
Rendus excessifs de frameworks — re-rendu de l'arborescence complète à chaque frappe clavier

Actions correctives par ordre d'efficacité :

Auditer les scripts tiers. La plupart des sites cumulent des tags oubliés. Supprimez les outils obsolètes et chargez les autres avec l'attribut defer ou après interaction.
Fractionner les tâches longues. Libérez le thread principal à l'aide de scheduler.yield() ou de setTimeout(…, 0).
Appliquer du debouncing sur les événements fréquents comme input et scroll.
Déporter les calculs intensifs dans un Web Worker.

Ordre de priorité des optimisations

Si votre temps est compté, procédez dans cet ordre :

Compresser et dimensionner l'image du LCP, ajouter fetchpriority="high". C'est le gain le plus spectaculaire, souvent réalisable en une heure.
Ajouter width et height à toutes les images. Règle l'essentiel du CLS rapidement.
Supprimer les chaînes @import bloquantes. Intégrer les polices dans le <head> avec preconnect.
Épurer les scripts tiers superflus. Soulage simultanément l'INP et le LCP.
Appliquer le chargement différé (loading="lazy") sur les images sous la ligne de flottaison.
Optimiser le TTFB s'il dépasse 600 ms. Chantier plus lourd, mais indispensable à toute la chaîne.

Un point de vue réaliste sur les scores

Viser un score parfait de 100 sur Lighthouse est souvent contre-productif. L'écart entre 85 et 100 n'influe quasiment pas sur le comportement de vos utilisateurs ; l'écart entre 35 et 75 le transforme radicalement.

Atteignez les seuils recommandés sur vos données de terrain pour les trois indicateurs, puis consacrez vos efforts à votre entonnoir de conversion. La performance technique est un vecteur de rentabilité, pas une fin en soi — et une page ultra-rapide dotée d'une offre peu attractive ne convertira pas davantage.

Ouvrir l'outil Audit SEO & Vitesse Données réelles Core Web Vitals issues de l'API Google, associées à des vérifications directes de votre code HTML.

Choisissez votre langue