Un guide pratique de Core Web Vitals expliqué

Trois métriques et pas dix : Core Web Vitals expliqué tient dans LCP, INP et CLS, qui décrivent ce que ressent l'utilisateur plutôt que ce que mesure un serveur.

Core Web Vitals est le petit ensemble de mesures de performances centrées sur l'utilisateur de Google : la plus grande peinture de contenu, l'interaction avec la peinture suivante et le changement de mise en page cumulatif. Ils sont importants car ils décrivent ce que ressentent les visiteurs : si la page se charge rapidement, répond lorsqu'elle est touchée ou cliqué, et évite de sauter partout.

La documentation Web Vitals actuelle de Google identifie LCP, INP et CLS comme Core Web Vitals stable et explique le cycle de vie des métriques (web.dev Web Vitals). INP a officiellement remplacé First Input Delay en tant que Core Web Vital le 12 mars 2024, comme Google l'a annoncé dans sa mise à jour Search Central.

Traitez Core Web Vitals comme un signal de diagnostic et d'expérience d'une page, et non comme un commutateur magique SEO. De meilleurs éléments vitaux peuvent aider les utilisateurs et éliminer un désavantage de classement, mais ils ne remplacent pas la pertinence, la qualité du contenu, l'autorité ou l'adéquation du produit.

Les Trois Core Web Vitals

La plus grande peinture de contenu (LCP)

LCP mesure le moment où le plus grand élément de contenu visible termine son rendu. Cet élément est, sur la plupart des pages, l'image de héros, un grand titre, une image de produit ou le bloc de contenu principal.

Cible : un bon LCP dure 2,5 secondes ou plus pour la plupart des chargements de pages.

Problèmes courants avec LCP :

• Réponse lente du serveur
• Grandes images de héros non optimisées
• CSS bloquant le rendu
• Retards de rendu côté client
• Polices Web bloquant le texte
• Chargement paresseux de l'image principale par erreur

Comment l'améliorer :

• Servez du HTML rapidement depuis le bord ou depuis une origine rapide.
• Compressez et redimensionnez les images des héros.
• Utilisez des formats modernes tels que AVIF ou WebP, le cas échéant.
• Préchargez la vraie image LCP.
• Intégrez ou priorisez les CSS critiques.
• Évitez de faire attendre le contenu principal pour des analyses, des outils de consentement ou des gestionnaires de balises.

Interaction avec Next Paint (INP)

INP mesure la réactivité à travers les interactions, pas seulement à la première entrée. Il capture le temps nécessaire à la page pour répondre visiblement après des clics, des pressions et des interactions au clavier.

Cible : le bon INP dure moins de 200 millisecondes.

INP est souvent blessé par JavaScript. Les tâches longues, l'hydratation, les scripts d'analyse, les widgets de discussion, les outils de personnalisation et les balises tierces lourdes peuvent tous rivaliser pour le fil principal.

Comment l'améliorer :

• Réduisez le JavaScript envoyé à la page.
• Divisez les gros paquets.
• Différez les scripts tiers non critiques.
• Évitez les travaux coûteux dans les gestionnaires de clics.
• Utilisez des Web Workers pour les calculs lourds.
• Divisez les tâches longues en morceaux plus petits.
• Testez les appareils mobiles bas de gamme, pas seulement les ordinateurs portables des développeurs.

Analytics peut affecter INP lorsqu'il attache un nombre excessif d'écouteurs d'événements, effectue un travail synchrone ou se charge via un gestionnaire de balises volumineux. Un petit script axé sur la vie privée n’est pas seulement meilleur pour la confiance ; c'est souvent mieux pour la réactivité.

Changement de mise en page cumulatif (CLS)

CLS mesure les mouvements visuels inattendus. Une page semble cassée lorsque le texte, les boutons ou les images se déplacent après que l'utilisateur commence à lire ou à appuyer.

Cible : le bon CLS est égal ou inférieur à 0,1.

Problèmes courants avec CLS :

• Images sans dimensions
• Annonces ou intégrations injectées sans espace réservé
• Bannières de cookies poussant le contenu après le chargement
• Échange tardif des polices Web
• Contenu dynamique inséré au-dessus du contenu existant

Comment l'améliorer :

• Définissez la largeur, la hauteur ou le rapport hauteur/largeur du média.
• Réservez de l'espace pour les bannières, les intégrations et les publicités.
• Évitez d'insérer du contenu au-dessus du pli après le chargement.
• Utilisez des stratégies de chargement de polices qui minimisent les décalages.
• Testez avec de vraies bannières de consentement et de vraies balises marketing activées.

Données de terrain vs données de laboratoire

Les outils de laboratoire tels que Lighthouse sont utiles pour le débogage car ils exécutent des tests contrôlés. Les données de terrain sont ce que les vrais utilisateurs ont expérimenté. Vous avez besoin des deux.

Utilisez les données de laboratoire pour reproduire et résoudre les problèmes. Utilisez les données de terrain pour établir des priorités. Une page qui obtient un bon score en laboratoire peut tout de même être lente pour de vrais visiteurs sur des appareils peu puissants, des réseaux mobiles congestionnés ou des navigateurs affectés par des scripts tiers.

Le rapport sur l'expérience utilisateur Chrome (CrUX) de Google est une source de données de terrain publiques pour les origines éligibles. Votre propre surveillance des utilisateurs réels peut être plus spécifique, car elle peut segmenter par modèle, appareil, campagne, état de connexion et version.

Lorsque vous mesurez les améliorations, gardez la méthode cohérente. Comparez les mêmes modèles, classes d'appareils, pays et fenêtres de version. Utilisez le 75e percentile, car les seuils Core Web Vitals sont évalués lors des chargements de pages, et non lors d'une exécution optimale sur un ordinateur portable de développeur.

Pourquoi les choix analytiques sont importants

Les budgets de performances se concentrent sur les images et les bundles d'applications tout en ignorant les scripts de mesure. C'est une erreur.

Les gestionnaires de balises peuvent charger plusieurs fournisseurs, chacun avec des requêtes réseau, une exécution JavaScript, des cookies et des écouteurs d'événements. Consent management platforms can also affect performance when they block rendering, inject late UI, or trigger tag re-evaluation after user choice.

Audit:

• Poids total des scripts tiers
• Nombre de requêtes réseau avant LCP
• Temps de blocage du thread principal provenant des analyses et des tags publicitaires
• Si les analyses se chargent avant le contenu critique
• Si l'interface utilisateur de consentement entraîne un changement de mise en page
• Si les balises inutilisées se déclenchent toujours

Supprimez les balises qui ne prennent pas en charge une décision actuelle. Remplacez les analyses lourdes par des mesures globales plus simples lorsque cela est possible.

Une commande d’optimisation pratique

1. Mesurez LCP, INP et CLS d'utilisateurs réels sur des modèles clés.
2. Identifiez le pire modèle, pas le pire individu URL.
3. Corrigez d'abord la réponse du serveur et la livraison de l'image LCP.
4. Supprimez ou différez le JavaScript non critique.
5. Réservez un espace de mise en page pour les médias, les intégrations, les publicités et les bannières.
6. Re-testez sur mobile.
7. Surveillez les données de terrain pendant au moins un cycle de trafic complet.

Ne recherchez pas un score Lighthouse parfait au détriment des vrais utilisateurs. Une page de paiement avec du JavaScript légèrement plus lourd peut être acceptable si elle est réactive et stable. Une page marketing sans logique d’application doit être extrêmement simple.

Core Web Vitals Contrôle qualité

Avant de crier victoire, vérifiez :

• Les données de laboratoire et de terrain ont toutes deux évolué dans la direction attendue.
• Les pires modèles mobiles améliorés, pas seulement la page d'accueil.
• Les bannières de consentement, GTM, les publicités, le chat et les analyses ont été activés lors de tests réalistes.
• Les modifications LCP, INP et CLS sont liées à la conversion, à l'inscription, à l'engagement dans le contenu, à la déviation du support ou à la qualité des revenus.
• Les résultats du backend sont rapprochés des analyses du navigateur lors de la mesure de l'impact commercial.

Séparez les mesures de diagnostic des mesures de décision. Un meilleur score INP explique pourquoi un formulaire semble plus rapide ; la mesure commerciale est de savoir si davantage de personnes le terminent.

L'essentiel

Core Web Vitals récompense le même comportement que les visiteurs récompensent déjà : un contenu rapide, des commandes réactives et des mises en page stables. Le chemin le plus rapide n’est pas exotique. Expédiez moins de JavaScript, donnez la priorité au contenu principal, réservez de l'espace et arrêtez de charger les balises qui ne méritent pas leur attention.

Questions fréquentes

Quels sont les trois Core Web Vitals ?

Les Core Web Vitals sont Largest Contentful Paint, Interaction to Next Paint et Cumulative Layout Shift. La documentation Web Vitals de Google désigne ces trois métriques comme les Core Web Vitals stables. Ensemble, elles couvrent le chargement, la réactivité et la stabilité visuelle, ce que la plupart des visiteurs remarquent réellement dans la vitesse d'une page.

Qu'est-ce qu'un bon score LCP ?

Un bon score LCP est de 2,5 secondes ou moins pour la plupart des chargements de page. Le LCP mesure le moment où le plus grand élément de contenu visible termine son rendu, souvent une image d'en-tête ou un grand titre. Une réponse serveur lente, des images d'en-tête non optimisées et du CSS bloquant le rendu sont les causes habituelles d'un mauvais score.

Qu'est-ce qu'un bon score INP ?

Un bon score INP est inférieur à 200 millisecondes. L'INP mesure le temps que met une page à réagir visiblement aux clics, aux appuis tactiles et aux saisies au clavier, pas seulement à la première interaction. Les tâches JavaScript longues, l'hydratation et les scripts tiers lourds sont les causes les plus courantes d'un mauvais score.

Qu'est-ce qu'un bon score CLS ?

Un bon score CLS est de 0,1 ou moins. Le CLS mesure les mouvements visuels inattendus, ceux qui se produisent quand du texte ou des boutons se déplacent pendant qu'un visiteur lit ou touche l'écran. Des images sans dimensions définies et des polices web qui s'échangent tardivement en sont des causes fréquentes.

Quand l'INP a-t-il remplacé le First Input Delay comme Core Web Vital ?

L'INP a officiellement remplacé le First Input Delay comme Core Web Vital le 12 mars 2024. Google a annoncé ce changement dans sa mise à jour Search Central. Ce basculement a fait passer la mesure de la réactivité d'une seule première interaction à l'ensemble des clics, des appuis tactiles et des frappes au clavier sur une page.

Les Core Web Vitals affectent-ils directement le classement Google ?

De meilleurs Core Web Vitals peuvent lever un désavantage de classement et améliorer l'expérience des visiteurs, mais ils ne fonctionnent pas comme un levier de classement isolé. Ce sont un outil de diagnostic et un signal d'expérience de page parmi d'autres. La pertinence, la qualité du contenu, l'autorité et l'adéquation au produit continuent de déterminer le résultat.

Quelle est la différence entre données de terrain et données de laboratoire ?

Les données de laboratoire proviennent d'outils contrôlés comme Lighthouse et servent à reproduire et corriger des problèmes précis. Les données de terrain reflètent ce que les utilisateurs réels ont réellement vécu sur leurs propres appareils et réseaux, et ce sont elles qui doivent guider les priorités. Une page peut obtenir un bon score en laboratoire et quand même mal se comporter pour des visiteurs réels sur des appareils lents ou des réseaux encombrés.

Pourquoi les scripts d'analyse peuvent-ils nuire à l'INP ?

Les scripts d'analyse peuvent nuire à l'INP quand ils ajoutent trop d'écouteurs d'événements, exécutent du travail synchrone ou se chargent via un gestionnaire de balises volumineux, ce qui monopolise le thread principal. Les gestionnaires de balises chargent souvent plusieurs fournisseurs à la fois, chacun avec ses propres requêtes réseau et son exécution JavaScript. Un script plus léger et respectueux de la vie privée pèse moins sur le thread principal tout en inspirant davantage confiance.

Pourquoi mesurer les Core Web Vitals au 75e centile ?

Les seuils des Core Web Vitals sont évalués sur l'ensemble des chargements de page, pas sur une seule exécution parfaite sur un ordinateur de développeur. Le 75e centile donne une vision réaliste de ce que vit la majorité des visiteurs, y compris les appareils et connexions les plus lents du lot. Comparer les mêmes gabarits, classes d'appareils, pays et fenêtres de mise en production à ce centile garde la mesure cohérente dans le temps.

Qu'est-ce qui cause généralement le Cumulative Layout Shift ?

Les causes courantes incluent des images ou contenus intégrés sans espace réservé, des publicités insérées sans taille fixe, des bannières de cookies qui repoussent le contenu après le chargement, et des polices web qui s'échangent tardivement. Du contenu dynamique inséré au-dessus de ce qui existe déjà sur la page est un autre déclencheur fréquent. Réserver l'espace pour les médias et les bannières à l'avance, et tester avec de vrais outils de consentement activés, règle la plupart de ces cas.