La plupart des visiteurs ne quittent pas une page lente parce qu'ils détestent la marque. Ils partent parce que l'attente est une friction, et la friction sur le premier écran tue la conversion. Les Core Web Vitals sont la tentative de Google de mesurer cette friction d'une manière dont développeurs et propriétaires de sites peuvent discuter.
Les trois indicateurs, traduits
LCP, Largest Contentful Paint
Le temps que met le contenu principal de la page à apparaître. Pour la plupart des sites, il s'agit de l'image d'accroche, du titre principal ou de la première photo de produit. Un bon LCP donne une impression de rapidité ; un mauvais LCP donne l'impression que la page réfléchit encore.
INP, Interaction to Next Paint
La réactivité de la page une fois que vous essayez d'interagir avec elle, cliquer sur un bouton, déployer un menu, ouvrir des filtres. Un mauvais INP donne l'impression que la page vous ignore un instant.
CLS, Cumulative Layout Shift
L'ampleur des sauts de contenu pendant le chargement de la page. Un mauvais CLS, c'est la sensation de tendre vers un bouton et de le voir se déplacer ailleurs, généralement parce qu'une publicité, une image ou une bannière s'est chargée en retard.
Pourquoi ces indicateurs affectent l'activité, pas seulement le SEO
- Un premier affichage lent signifie que les gens ferment l'onglet avant que le contenu n'apparaisse.
- Des interactions peu réactives donnent l'impression que les formulaires, filtres et tunnels d'achat sont cassés.
- Les décalages de mise en page provoquent des clics ratés, qui créent frustration, retours et tickets de support.
- Google utilise ces indicateurs comme signal de classement, de sorte qu'une mauvaise performance réduit aussi la fréquence à laquelle on vous trouve.
L'impact est cumulatif : les petits problèmes de performance s'additionnent au fil des sessions, et les petites améliorations se cumulent aussi.
Ce qui fait généralement la plus grande différence
- Les images. Correctement dimensionnées, dans des formats modernes (WebP/AVIF), en chargement différé sous la ligne de flottaison, et avec des dimensions explicites pour que le navigateur n'ait pas à deviner.
- Les polices. Limitez-les à ce que vous utilisez réellement, hébergez-les vous-même quand c'est possible, et préchargez celle qui affiche le texte d'accroche.
- Les scripts tiers. Analyses, widgets de chat, outils d'A/B et gestionnaires de balises sont souvent la plus grande source d'un INP lent. Chargez-les en différé, et uniquement sur les pages où ils sont nécessaires.
- Le JavaScript inutilisé. Livrer moins de code signifie moins d'analyse, moins d'exécution, moins d'énergie sur les appareils d'entrée de gamme.
- Le temps de réponse du serveur. Un backend lent impose un plancher à tout le reste. La mise en cache, l'optimisation des requêtes et un niveau d'hébergement sensé comptent.
- L'espace réservé. Utilisez une largeur/hauteur explicite ou des ratios d'aspect CSS pour les images, publicités, iframes et bannières afin que la mise en page ne saute pas plus tard.
Erreurs courantes
- Mesurer uniquement sur votre propre ordinateur portable rapide. Les utilisateurs sont sur des réseaux mobiles et des appareils milieu de gamme. Utilisez des données de terrain (surveillance des utilisateurs réels) en parallèle des tests en laboratoire.
- Courir après un seul chiffre. Un score Lighthouse parfait sur une exécution ne signifie pas grand-chose ; des indicateurs de terrain cohérents sur plusieurs semaines, si.
- Ajouter des outils pour corriger la performance. Davantage de scripts rendent rarement un site plus rapide.
- Traiter la performance comme un ponctuel. Sans surveillance, elle régresse chaque fois que l'équipe ajoute un nouveau widget.
Une séquence sensée
- Obtenez des données de terrain de référence pour LCP, INP et CLS sur vos 5 pages principales.
- Corrigez d'abord l'image d'accroche et le titre principal, ils affectent le LCP de façon disproportionnée.
- Auditez les scripts tiers ; supprimez ou différez tout ce qui n'est pas strictement nécessaire.
- Réservez l'espace pour les images, publicités et éléments à chargement tardif.
- Surveillez en continu, et traitez les régressions comme des bugs.
