Comment améliorer les Core Web Vitals : guide pratique du LCP, de l'INP et du CLS

Les Core Web Vitals sont trois mesures que Google utilise pour décrire l'expérience de chargement et d'utilisation d'une page : la rapidité d'apparition du contenu principal, la rapidité de réaction de la page lorsqu'on interagit avec elle, et l'ampleur des sauts de mise en page. Ils entrent dans la façon dont Google évalue l'expérience sur la page, même si un contenu pertinent et utile pèse bien davantage dans le classement. Ils donnent surtout une bonne idée de l'impression de rapidité que laisse votre site.

Les trois indicateurs et les seuils à atteindre

• Largest Contentful Paint (LCP) : le moment où la plus grande image ou le plus grand bloc de texte de la zone visible est affiché. Bon : 2,5 secondes ou moins ; mauvais : plus de 4 secondes.
• Interaction to Next Paint (INP) : le temps que met la page à réagir visiblement aux clics, aux taps et aux frappes au clavier, sur l'ensemble de la visite. Bon : 200 millisecondes ou moins ; mauvais : plus de 500 ms. L'INP a remplacé le First Input Delay parmi les Core Web Vitals en mars 2024.
• Cumulative Layout Shift (CLS) : l'ampleur des déplacements inattendus du contenu visible. Bon : 0,1 ou moins ; mauvais : plus de 0,25.

Une page est conforme lorsque 75 % des chargements de page (le 75e centile) atteignent le seuil « bon » pour chaque indicateur, la mesure étant faite séparément pour le mobile et l'ordinateur. Autrement dit, le quart le plus lent de vos visiteurs ne joue pas contre vous, mais le visiteur type équipé d'un téléphone de milieu de gamme, si.

Données de laboratoire et données de terrain

Les données de terrain proviennent de vrais visiteurs. Le Chrome UX Report de Google les collecte auprès des utilisateurs de Chrome qui y ont consenti, sur une fenêtre glissante de 28 jours, et ce sont elles qu'affichent le rapport Core Web Vitals de Search Console et le haut de PageSpeed Insights. Ce sont les données qui comptent, mais elles exigent un trafic suffisant et évoluent lentement.

Les données de laboratoire proviennent d'un chargement unique de la page en conditions contrôlées, comme le fait Lighthouse. Elles sont disponibles instantanément pour n'importe quelle page et montrent pourquoi un indicateur est lent, ce qui en fait l'outil du diagnostic. Mais un seul test de laboratoire sur un téléphone simulé ne reflétera pas les appareils et réseaux réels de vos visiteurs, et un test de laboratoire ne peut pas du tout mesurer l'INP, puisque personne n'interagit avec la page. Le Total Blocking Time (TBT), c'est-à-dire le temps pendant lequel le thread principal est trop occupé pour réagir durant le chargement, est le signal de laboratoire le plus proche.

Utilisez les deux : les données de terrain pour savoir si vous avez un problème et si votre correctif a fonctionné ; les données de laboratoire pour en trouver la cause. Pour collecter vos propres données de terrain, la bibliothèque JavaScript open source web-vitals transmet à votre outil d'analyse d'audience les trois indicateurs mesurés lors de visites réelles.

Améliorer le LCP

Le temps de LCP se décompose en quatre parties : le time to first byte, le délai avant que le navigateur ne commence à charger la ressource LCP, le temps de téléchargement de celle-ci et le délai avant son affichage. Repérez la partie qui pèse le plus, puis :

• Accélérez la réponse du serveur avec un cache de pages et un CDN, pour que le HTML arrive vite.
• Faites en sorte que l'image LCP soit découverte tôt : utilisez un <img> classique dans le HTML plutôt qu'un arrière-plan CSS ou une image injectée par JavaScript, et ne lui appliquez jamais loading="lazy".
• Donnez-lui la priorité : ajoutez fetchpriority="high" à l'image LCP, ou préchargez-la si elle est référencée tardivement.
• Allégez-la : servez-la à sa taille d'affichage, en WebP ou en AVIF. Voir comment réduire le poids des images.
• Supprimez les ressources qui bloquent le rendu : intégrez le CSS critique directement dans la page, différez les scripts non essentiels et évitez un rendu côté client volumineux avant l'apparition du contenu principal.

Améliorer l'INP

L'INP est lent lorsque le thread principal du navigateur est occupé, le plus souvent à exécuter du JavaScript, au moment où quelqu'un interagit, ou lorsque le travail déclenché par l'interaction met longtemps à s'afficher.

• Livrez moins de JavaScript. Supprimez les bibliothèques et extensions inutilisées, découpez les bundles et n'hydratez pas les parties de la page qui n'ont pas besoin d'être interactives.
• Fractionnez les tâches longues. Découpez tout traitement de plus de 50 ms en morceaux plus petits et rendez la main au navigateur entre deux, avec setTimeout ou scheduler.yield() là où il est pris en charge.
• Faites-en moins dans les gestionnaires d'événements. Mettez d'abord l'interface à jour, puis effectuez le travail coûteux ; appliquez un debounce aux gestionnaires de saisie.
• Passez en revue les scripts tiers. Les widgets de chat, les gestionnaires de balises et les outils de tests A/B exécutent souvent du code lourd à chaque interaction. Chargez-les plus tard, ou seulement en cas de besoin.
• Gardez un DOM de taille raisonnable, car un DOM volumineux ralentit chaque nouveau rendu.

Améliorer le CLS

• Donnez des dimensions aux images et aux vidéos avec les attributs width et height ou la propriété CSS aspect-ratio, afin que l'espace soit réservé avant leur chargement.
• Réservez l'espace des publicités, des contenus intégrés et des bandeaux. Donnez une hauteur minimale à leurs conteneurs, et n'insérez pas de contenu au-dessus de ce que le visiteur est déjà en train de lire.
• Domptez les polices web. Utilisez font-display: swap ou optional, préchargez les polices clés et choisissez une police de remplacement aux métriques ajustées (size-adjust) pour réduire le décalage à l'arrivée de la police web.
• Animez avec transform, et non avec des propriétés comme top ou height, qui déplacent le contenu environnant.
• Laissez le cache amont-aval (back/forward cache) faire son travail, en évitant les gestionnaires unload, pour que les retours sur une page la restaurent instantanément, sans décalage.

Ce que Rudra apporte

L'outil gratuit de test de vitesse lance un seul test de laboratoire Lighthouse, avec sa simulation mobile par défaut. Chaque indicateur est affiché avec sa valeur mesurée, présentée comme une mesure de laboratoire issue d'une seule exécution, et comparé aux seuils publiés : LCP 2,5 s / 4 s, CLS 0,1 / 0,25, TBT 200 / 600 ms. Les audits en échec énumèrent jusqu'à cinq des fichiers ou éléments en cause, avec les économies estimées, pour que vous sachiez par où commencer. L'outil ne mesure pas l'INP et n'inclut pas de données de terrain ; consultez-les dans Search Console ou PageSpeed Insights. Pour comprendre ce qui ralentit une page dans son ensemble, voir pourquoi mon site web est-il lent.

Une méthode qui fonctionne

1. Consultez le rapport Core Web Vitals de Search Console pour savoir quel indicateur échoue, et sur quel groupe de pages.
2. Choisissez une page représentative de ce groupe et lancez plusieurs fois un test de laboratoire.
3. Corrigez d'abord la cause principale, déployez, puis refaites le test en laboratoire.
4. Attendez la mise à jour des données de terrain (la fenêtre est de 28 jours) avant de juger le résultat.