Core Web Vitals expliqués : LCP, INP et CLS en termes simples

Les Core Web Vitals ne sont pas un test de personnalité pour votre site web

Les Core Web Vitals sont souvent traités comme un bulletin de notes mystérieux. Une page reçoit un chiffre rouge, quelqu’un publie une capture d’écran dans Slack, et l’équipe commence à débattre des frameworks JavaScript.

Ce n’est pas particulièrement utile.

La meilleure façon d’aborder les Core Web Vitals est plus simple : ce sont trois mesures qui indiquent si une page semble utilisable pour une vraie personne sur un vrai appareil. Elles ne couvrent pas tous les aspects de la performance, de l’accessibilité ou de la qualité. Mais elles repèrent trois sources fréquentes de frustration :

• Le contenu principal met trop de temps à apparaître.
• La page réagit lentement lorsque l’utilisateur essaie de faire quelque chose.
• La mise en page se déplace pendant que l’utilisateur lit ou appuie.

Ce sont les trois Core Web Vitals : LCP, INP et CLS.

Google les utilise dans ses signaux d’expérience de page, mais l’angle SEO n’est pas la meilleure raison de s’y intéresser. La meilleure raison, c’est que les pages lentes, instables et peu réactives font perdre du temps aux utilisateurs. Elles ont aussi tendance à moins bien convertir, à générer plus de support et à mal vieillir.

Les trois métriques en une phrase chacune

Avant d’entrer dans les détails, voici la version en termes simples :

• LCP, ou Largest Contentful Paint, mesure le temps nécessaire pour charger le contenu visible principal.
• INP, ou Interaction to Next Paint, mesure la rapidité avec laquelle la page répond aux interactions utilisateur pendant la visite.
• CLS, ou Cumulative Layout Shift, mesure dans quelle mesure la page se déplace de manière inattendue.

Les seuils habituels sont :

| Metric | Good | Needs improvement | Poor | |---|---:|---:|---:| | LCP | 2,5 s ou moins | 2,5 s–4,0 s | Plus de 4,0 s | | INP | 200 ms ou moins | 200 ms–500 ms | Plus de 500 ms | | CLS | 0,1 ou moins | 0,1–0,25 | Plus de 0,25 |

Ces chiffres sont normalement évalués au 75e percentile des visites d’utilisateurs réels. C’est important. Vous n’essayez pas d’obtenir une exécution parfaite en laboratoire. Vous essayez de rendre l’expérience bonne pour la plupart des utilisateurs, y compris les personnes sur des téléphones plus lents et des réseaux moins fiables.

Si vous regardez un rapport automatisé sans savoir par où commencer, il est utile de séparer le diagnostic de la panique. Nous avons un guide séparé sur la façon de lire un rapport Lighthouse sans paniquer, qui détaille davantage ce flux de travail.

LCP : quand la page semble-t-elle chargée ?

Le Largest Contentful Paint mesure le temps de rendu du plus grand élément de contenu visible dans la fenêtre d’affichage. En pratique, il s’agit souvent :

• d’une image hero,
• d’un grand titre,
• d’une image d’article mise en avant,
• d’une image de produit,
• d’un grand bloc de texte.

Le LCP ne demande pas quand chaque script, pixel de suivi et image sous la ligne de flottaison a fini de charger. Il demande : quand l’élément principal que l’utilisateur est venu voir est-il devenu visible ?

Cela fait du LCP une métrique plus humaine que l’ancien « temps de chargement de la page ». Une page peut techniquement finir de charger tard tout en semblant rapide si le contenu principal apparaît rapidement. L’inverse est également vrai : une page peut déclencher l’événement load alors que la zone hero est encore vide, floue ou bloquée par un délai de rendu.

Causes fréquentes d’un mauvais LCP

La plupart des problèmes de LCP médiocres viennent de quelques endroits prévisibles :

1. Réponse serveur lente

Si le document HTML arrive en retard, tout le reste commence en retard.

1. CSS ou JavaScript bloquant le rendu

Le navigateur a le contenu, mais ne peut pas encore l’afficher.

1. Images hero non optimisées

Le plus grand élément est trop lourd, dans le mauvais format, non priorisé ou chargé en lazy loading par erreur.

1. Polices web qui retardent le rendu du texte

Un grand titre peut être l’élément LCP, et le chargement des polices peut le retarder ou le modifier visuellement.

1. Délais de rendu côté client

Si la page a besoin d’un gros bundle JavaScript avant de pouvoir afficher du contenu significatif, le LCP en souffre.

Comment améliorer le LCP

Commencez par l’élément LCP réel. N’optimisez pas des ressources au hasard avant de savoir ce que le navigateur mesure.

Les correctifs pratiques incluent :

• Servir le HTML rapidement : mettre en cache lorsque c’est approprié, réduire le travail backend, éviter les redirections lentes.
• Optimiser l’image LCP : utiliser les bonnes dimensions, la bonne compression et le bon format.
• Ne pas charger en lazy loading l’image hero située au-dessus de la ligne de flottaison.
• Utiliser fetchpriority="high" avec prudence pour l’image principale lorsqu’elle est réellement prioritaire.
• Inliner le CSS critique uniquement lorsque cela réduit réellement le délai de rendu.
• Réduire le JavaScript nécessaire avant le premier rendu significatif.
• Utiliser font-display: swap ou une autre stratégie de polices délibérée.

Les images et les polices sont souvent en cause. Pour les images, le compromis ne se résume pas à « petit fichier = bien ». Le choix du format, l’effort d’encodage et la prise en charge par les navigateurs comptent tous, c’est pourquoi nous conservons un arbre de décision pratique pour savoir quand AVIF surpasse WebP, et quand ce n’est pas le cas. Pour les pages riches en texte, les polices web restent l’un des gains de performance les plus faciles, car de nombreux sites livrent plus de fichiers de polices qu’ils n’en utilisent.

INP : la page répond-elle lorsqu’on la touche ?

L’Interaction to Next Paint mesure la réactivité. Plus précisément, elle examine le délai entre une interaction utilisateur et la prochaine mise à jour visuelle après que le navigateur a traité cette interaction.

Les interactions incluent par exemple :

• cliquer sur un bouton,
• appuyer sur un menu,
• sélectionner une case à cocher,
• saisir du texte dans un champ de formulaire,
• ouvrir un accordéon.

L’INP a remplacé le First Input Delay comme Core Web Vital en 2024. C’était une bonne évolution. Le First Input Delay ne regardait que la première interaction. L’INP est plus large : il prend en compte les interactions tout au long de la visite de la page et signale une interaction à forte latence comme score de réactivité de la page.

En clair : l’INP détecte les pages qui semblent chargées, mais donnent l’impression d’être bloquées.

Vous avez probablement déjà utilisé une page comme celle-ci. Elle semble prête. Vous appuyez sur le menu. Rien ne se passe pendant une demi-seconde. Vous appuyez à nouveau. Puis deux choses se produisent en même temps. C’est un problème d’INP.

Causes fréquentes d’un mauvais INP

L’INP est généralement un problème de thread principal. Le navigateur veut répondre, mais JavaScript, le travail de rendu ou le calcul de mise en page l’en empêche.

Les causes typiques incluent :

• de gros bundles JavaScript,
• des gestionnaires d’événements coûteux,
• le travail d’hydratation sur les applications rendues côté client,
• des scripts tiers en concurrence pour le thread principal,
• des tâches longues après le chargement de la page,
• des mises à jour complexes du DOM déclenchées par de petites interactions,
• du layout thrashing, où le code lit et écrit de manière répétée des valeurs de mise en page.

Les balises marketing, l’analytics, les widgets de chat et les bandeaux de consentement peuvent tous contribuer au problème. Cela ne signifie pas « tout supprimer ». Cela signifie que chaque script sur la page a un coût, et que la latence d’interaction est souvent l’endroit où ce coût devient visible.

Comment améliorer l’INP

Améliorer l’INP consiste moins à trouver un attribut magique qu’à réduire la contention sur le thread principal.

Les approches utiles incluent :

• Découper les longues tâches JavaScript en morceaux plus petits.
• Différer le travail non essentiel jusqu’à ce que la page soit utilisable.
• Supprimer le JavaScript inutilisé plutôt que de simplement le minifier.
• Garder les gestionnaires d’événements petits et prévisibles.
• Éviter de rerendre de grandes parties de l’interface pour de minuscules changements d’état.
• Utiliser CSS pour les états visuels simples lorsque c’est possible.
• Auditer les scripts tiers et ne les charger que là où ils sont nécessaires.

Regardez aussi la conception des interactions. Un bouton qui donne un retour visuel immédiat peut sembler plus réactif, même si le travail qui suit prend plus de temps. Ce n’est pas un substitut à la performance, mais cela fait partie d’une bonne ingénierie d’interface. Notre checklist pour des boutons web accessibles recoupe ce sujet : des états clairs, une sémantique correcte et un comportement prévisible aident à la fois les utilisateurs et les navigateurs.

CLS : la page reste-t-elle là où l’utilisateur l’attend ?

Le Cumulative Layout Shift mesure le déplacement inattendu des éléments visibles. Si un utilisateur commence à lire un paragraphe et qu’une publicité, une image ou un bandeau se charge au-dessus, poussant le texte vers le bas, cela contribue au CLS.

Le CLS ne se mesure pas en secondes. C’est un score basé sur la quantité de contenu déplacée et la distance sur laquelle il s’est déplacé. Plus il est bas, mieux c’est.

Le mot clé est inattendu. Les changements de mise en page causés par une action utilisateur ne sont généralement pas comptés de la même manière. Si quelqu’un appuie sur « afficher plus » et que du contenu se déploie, c’est attendu. Si un bandeau de newsletter apparaît en haut après trois secondes et pousse tout vers le bas, ça ne l’est pas.

Causes fréquentes d’un mauvais CLS

Les échecs de CLS sont souvent ordinaires :

• des images sans attributs width et height,
• des publicités ou contenus intégrés sans espace réservé,
• des bandeaux de cookies insérés au-dessus du contenu,
• des polices web qui se substituent avec des métriques différentes,
• des barres promotionnelles chargées tardivement,
• du contenu injecté dynamiquement près du haut de la page.

La correction consiste généralement à réserver l’espace avant l’arrivée du contenu. Le navigateur devrait connaître la forme de la page le plus tôt possible.

Comment améliorer le CLS

Commencez par les déplacements visibles. Regardez un enregistrement ou utilisez les outils du navigateur pour identifier les éléments qui bougent.

Appliquez ensuite les correctifs ennuyeux :

• Ajouter des attributs width et height explicites aux images.
• Utiliser CSS aspect-ratio pour les conteneurs média responsives.
• Réserver un espace fixe ou minimal pour les publicités, les contenus intégrés et les iframes.
• Éviter d’injecter des bandeaux au-dessus du contenu existant après le chargement.
• Choisir des polices de repli avec des métriques similaires à celles de la police finale.
• Éviter les animations qui modifient des propriétés de mise en page comme top, left, width ou height; préférer les transformations.

Le CLS est l’une des rares métriques de performance où la discipline l’emporte sur l’ingéniosité. Si la page a des boîtes stables, elle a tendance à obtenir un bon score.

Les données de terrain et les données de laboratoire sont toutes deux utiles, mais elles répondent à des questions différentes

Une source fréquente de confusion est que différents outils affichent différents chiffres. C’est normal.

Les données de terrain viennent de vrais utilisateurs. Elles reflètent les appareils, réseaux, lieux et conditions de navigateur réels. Le Chrome User Experience Report de Google est un exemple de données de terrain.

Les données de laboratoire viennent d’un environnement de test contrôlé. Lighthouse en est l’exemple familier. Elles sont répétables et utiles pour le débogage, mais elles ne sont pas identiques à l’expérience vécue par vos utilisateurs.

Utilisez les données de terrain pour décider si les utilisateurs ont un vrai problème. Utilisez les données de laboratoire pour reproduire et déboguer ce problème.

Souvenez-vous aussi que les Core Web Vitals sont généralement évalués par URL ou groupe d’URL, et non comme une propriété abstraite unique de votre marque. Votre page d’accueil, votre article de blog, votre page de tarifs et votre checkout peuvent avoir des goulets d’étranglement très différents.

Un ordre de travail raisonnable

Si les trois métriques sont mauvaises, la tentation est de commencer partout. Résistez.

Un ordre pratique est :

1. Corriger d’abord les problèmes de CLS évidents

Les dimensions d’image manquantes et les bandeaux instables sont souvent des gains rapides.

1. Améliorer le LCP des templates importants

Concentrez-vous sur les pages qui comptent : pages produit, landing pages, articles, parcours d’inscription.

1. Étudier l’INP avec de vraies interactions

Cliquez sur les éléments que les utilisateurs cliquent réellement. Les menus, filtres, formulaires et contrôles de checkout en révèlent souvent plus que la trace du chargement initial.

1. Auditer les scripts tiers

Gardez ceux qui justifient leur coût. Supprimez ou retardez ceux qui ne le justifient pas.

1. Définir un budget de performance

Sans budget, les améliorations de performance se dégradent. De nouveaux scripts, images et composants de design annuleront discrètement le travail.

Le point important : n’optimisez pas pour un badge. Optimisez pour le parcours utilisateur. Une amélioration marginale du score sur une page peu fréquentée peut compter moins qu’une interaction de checkout légèrement imparfaite, mais beaucoup plus rapide.

<!-- tool-cta:start -->

💡 Essayez ceci : Puisque le LCP est généralement un problème d’image, réduisez la taille de votre visuel hero avec Image Compressor pour obtenir un premier gain facile.

<!-- tool-cta:end -->

Ce que les Core Web Vitals ne vous disent pas

Les Core Web Vitals sont utiles, mais incomplets.

Ils ne vous disent pas si votre contenu est bon. Ils ne vous disent pas si votre navigation a du sens. Ils ne garantissent pas l’accessibilité. Ils ne mesurent pas la confidentialité, la sécurité, la confiance, la lisibilité ni le fait que la page réponde à la question de l’utilisateur.

Ils ne remplacent pas non plus le jugement. Une page peut réussir les Core Web Vitals et rester désagréable. Une application complexe peut manquer un seuil tout en étant conçue de manière responsable compte tenu de ses contraintes.

Traitez LCP, INP et CLS comme des détecteurs de fumée. Lorsqu’ils se déclenchent, enquêtez. Lorsqu’ils sont silencieux, continuez à entretenir le bâtiment.