Qu est-ce que les Core Web Vitals ?
Les Core Web Vitals sont trois mesures que Google utilise pour décrire ce que l'on ressent réellement en utilisant une page : la vitesse d'apparition du contenu principal, la réactivité de la page à la sollicitation et l'ampleur des décalages de mise en page pendant le chargement. Ce n'est pas le seul facteur de classement, mais pour les sites B2B qui se disputent des requêtes de service de longue traîne, elles décident souvent qui obtient le clic.
Pourquoi elles comptent pour les décisions d'achat B2B
Une page lente ne gêne pas seulement le visiteur : elle modifie son comportement. Études et audits réels montrent de façon constante que les pages plus lentes qu'environ trois secondes perdent une part significative de leurs visiteurs avant même qu'ils aient lu quoi que ce soit. Pour une entreprise B2B qui enchérit sur des termes de service à forte valeur, une fraction de seconde sur mobile peut faire la différence entre une demande qualifiée et un rebond qui profite au concurrent.
LCP : Chargement
Le Largest Contentful Paint mesure le temps nécessaire au plus grand élément visible - généralement une image principale ou un titre - pour finir de s'afficher. L'objectif est de rester sous 2,5 secondes. Sur les sites B2B, les coupables habituels sont une photographie principale non optimisée, une police qui bloque le rendu et un widget de chat tiers qui se charge avant le contenu de la page.
Qu'est-ce qui est bon, à améliorer ou mauvais
Google regroupe chaque mesure en trois seuils. Pour le LCP, moins de 2,5 secondes est bon, 2,5 à 4 secondes est à améliorer, et plus de 4 secondes est mauvais. Le score reposant sur des données de terrain réelles de vos visiteurs réels, et non sur un test de laboratoire, une page peut paraître correcte sur la connexion rapide du bureau tout en restant médiocre pour un prospect sur un réseau mobile lent.
Causes B2B courantes d'un LCP lent
Les causes les plus fréquentes que nous voyons sont des images principales lourdes et non compressées exportées directement depuis l'outil du designer, des polices chargées depuis un fournisseur externe qui bloquent le rendu, et plusieurs scripts tiers - chat, analyse, gestionnaire de balises, pixels marketing - empilés dans l'en-tête avant le contenu. Chacun ajoute du retard, et tous ensemble franchissent facilement les quatre secondes.
INP : Interactivité
L'Interaction to Next Paint a remplacé le First Input Delay comme mesure de réactivité. Il évalue le pire délai entre une action de l'utilisateur - ouvrir un menu, appuyer sur un bouton, envoyer un formulaire - et l'image suivante que le navigateur parvient à peindre. Les paquets d'analyse lourds, les scripts de chat et les grands frameworks JavaScript font grimper ce chiffre, et la correction commence le plus souvent par retirer du code plutôt que par en ajouter.
Quel est un bon score INP
Un INP inférieur à 200 millisecondes est bon, de 200 à 500 millisecondes est à améliorer, et au-delà de 500 millisecondes est mauvais. Sur un site B2B, cela compte parce que les actions de l'acheteur - ouvrir la navigation, filtrer une liste de produits, démarrer une demande de devis - sont précisément les instants où une réponse lente le convainc d'essayer ailleurs.
Ce qui ralentit habituellement l'INP
Les coupables habituels sont des paquets JavaScript surdimensionnés, un gestionnaire de balises qui déclenche trop de scripts d'un coup, des chatbots qui accaparent le thread principal au chargement, et des intégrations tierces mal écrites comme des cartes ou des calculateurs. La première étape de diagnostic n'est que rarement de prendre un hébergement plus rapide ; c'est d'auditer le code qui s'exécute vraiment sur chaque page et de supprimer ce dont personne n'a besoin.
CLS : Stabilité visuelle
Le Cumulative Layout Shift note l'ampleur des déplacements visibles de la page pendant le chargement. Une bannière de cookies qui pousse toute la mise en page vers le bas, des images sans attributs de largeur et de hauteur, et des polices injectées tardivement en sont les causes classiques. C'est la plus facile des trois à corriger et la plus désagréable à subir pour un visiteur.
Les causes habituelles des décalages de mise en page
Les décalages les plus courants viennent de l'insertion d'une bannière ou d'un interstitiel après l'affichage de la page, d'images et de vidéos sans dimensions réservées, de polices web qui basculent depuis une police de secours une fois chargées, et de widgets de génération de leads ou de publicités injectés dynamiquement. Corriger cela consiste surtout à réserver l'espace dans le balisage, pour que le navigateur connaisse la taille de chaque élément avant de peindre.
Comment les mesurer et les corriger
Commencez par des données réelles utilisateurs, pas par un test de laboratoire synthétique. Consultez le rapport de terrain dans Google Search Console pour trouver les URL réelles où vos visiteurs butent, puis reproduisez les pires cas sur une connexion mobile bridée. Corrigez d'abord la page qui envoie le plus de trafic et a le moins bon score, puis passez à la suivante.
Depuis où mesurer
Les outils de terrain, comme le rapport sur l'expérience utilisateur Chrome et Search Console, montrent ce que vivent vos vrais visiteurs ; les outils de laboratoire, comme Lighthouse, montrent ce que vous pouvez améliorer. Utilisez les données de terrain pour décider quoi corriger et les outils de laboratoire pour vérifier que la correction a fonctionné. Ne vous optimisez pas uniquement contre un score de laboratoire, car les conditions du labo ressemblent rarement à un atelier sur réseau mobile.
Questions fréquentes
Les questions que nous posent le plus souvent les responsables marketing et informatique B2B avant de démarrer un travail sur les performances.
Les Core Web Vitals décident-ils directement du classement Google ?
Ce sont un signal de classement parmi d'autres, pas une règle qui fait bouger les positions à elle seule. Leur effet est indirect mais réel : les pages plus rapides et plus réactives retiennent mieux, engagent davantage et convertissent mieux, et ce sont ces signaux comportementaux que Google récompense. Corriger les indicateurs donne rarement un bond magique, mais les ignorer sur des termes concurrentiels constitue un vrai handicap.
Lequel des trois faut-il corriger en premier ?
Commencez par celui que vos données de terrain montrent comme le pire sur vos pages les plus fréquentées. En pratique, le CLS est souvent le gain le plus rapide car il se corrige surtout dans le balisage, le LCP vient ensuite avec le travail sur les images et les polices, et l'INP prend plus longtemps car il faut retirer ou différer du JavaScript. Séquencez par effort et impact plutôt que de vous attaquer aux trois à la fois.
Les Core Web Vitals sont-ils mesurés sur ordinateur ou sur mobile ?
Google les publie séparément pour mobile et ordinateur, et les scores mobiles pèsent généralement le plus pour le classement. L'essentiel de la recherche B2B se faisant désormais sur téléphone, traitez les chiffres mobiles comme ceux qui comptent et testez vos corrections sur une connexion 3G bridée, pas sur le Wi-Fi rapide du bureau.
Conclusion
Traitez les Core Web Vitals comme une routine de maintenance, pas comme un projet. Mesurez sur de vrais appareils, corrigez d'abord la page la plus mauvaise, et revérifiez après chaque refonte ou intégration tierce. Si vous préférez confier cette routine à quelqu'un d'autre, c'est exactement ce que couvre notre travail sur la performance.