CORRIGER CHAQUE INDICATEUR WEB VITAL DE BASE
Trois indicateurs, trois métiers différents. Les solutions concrètes qui font évoluer chacun d'entre eux, sans se perdre dans la théorie.
← Tous les guides Tous les guides de ce sujet
LCP : optimiser la vitesse de chargement du contenu principal
Le « Largest Contentful Paint » correspond généralement à une image phare, un gros titre ou une image d'affiche. Identifiez cet élément. Tout le reste est secondaire tant que son chargement n'est pas rapide.
Les leviers permettant d'influencer le LCP : compresser et redimensionner la ressource, utiliser un format moderne, définir ses dimensions, précharger l'URL exacte lorsqu'elle n'est pas disponible immédiatement, la placer sur un CDN et réduire le TTFB afin que le téléchargement puisse commencer. Évitez le chargement différé de l'image LCP. Évitez les carrousels qui retardent l'affichage du véritable nœud LCP.
Point de vue du serveur : si le code HTML lui-même est en retard, aucune astuce liée aux images ne pourra vous sauver. Commencez par régler les problèmes de cache et de source.
Point clé : identifiez l'élément LCP, puis optimisez le chargement de ce fichier et de son chemin d'accès pour qu'ils soient d'une rapidité impressionnante.
INP : ne pas encombrer le thread principal
L'indicateur « Interaction to Next Paint » mesure la rapidité avec laquelle la page réagit après un tapotement ou un clic. Les scripts JavaScript lourds exécutés sur le thread principal en sont généralement la cause : une « hydration » importante, des gestionnaires coûteux, des scripts tiers qui s'exécutent indéfiniment.
Mesures à prendre : supprimer ou différer les éléments tiers, fractionner les gestionnaires, éviter les composants synchrones volumineux sur les pages marketing, privilégier le HTML rendu côté serveur avec de petits « îlots », et effectuer les tests sur un véritable appareil Android de milieu de gamme, et non pas uniquement à l'aide d'un préréglage de limitation de débit sur ordinateur de bureau.
Point clé : l'INP s'améliore lorsque l'on décharge le thread principal, et non lorsque l'on procède à des micro-optimisations d'une transition CSS.
CLS : empêcher la page de sauter
Le « Cumulative Layout Shift » correspond à une instabilité visuelle. Il s'agit notamment d'images sans dimensions définies, de polices qui s'affichent tardivement et modifient la taille du texte, de publicités et d'éléments intégrés qui créent un vide dans la mise en page, ainsi que de bannières insérées au-dessus du contenu.
Leviers : largeur et hauteur ou rapport d'aspect CSS selon le support, emplacements réservés aux publicités, stratégies d'affichage des polices qui ne perturbent pas la mise en page, et absence d'interface utilisateur chargée tardivement au-dessus du contenu existant. Privilégier la transformation de l'espace existant plutôt que l'insertion de nouveaux blocs en haut de la page.
Point à retenir : si quelque chose doit apparaître plus tard, réservez-lui de l'espace dès maintenant.
Les erreurs qui reviennent sans cesse à chaque fois
| Système métrique | Erreur courante | On ferait mieux de partir |
|---|---|---|
| LCP | Chargement différé du héros | Eager + précharger l'URL réelle du LCP |
| LCP | Optimisation d'une image non-LCP | Commencez par identifier le nœud LCP |
| INP | Les animations CSS sont à blâmer | Supprimer le code JS et les éléments tiers |
| INP | Test effectué uniquement sur ordinateur de bureau | Optez pour un téléphone de milieu de gamme |
| CLS | Ignorer les paramètres typographiques | Polices de sous-ensemble, espace réservé |
| CLS | Bannières de cookies sans espace | Réservez ou superposez avec soin |
Point clé : la plupart des échecs répétés sont dus à des erreurs de processus, et non à l'absence de micro-optimisations.
Comment réussir les trois
Ordre des opérations à effectuer sur un site défaillant : effacer le LCP, puis l'INP, puis le CLS. Remesurer les données de terrain entre chaque étape. Utilisez la liste de contrôle CWV comme point de départ et le guide « slow-site » si vous ne parvenez toujours pas à distinguer le serveur du front-end.
Il suffit d'atteindre le 75e centile pour ces trois critères sur mobile. Ne retardez pas la mise en production dans l'attente d'un score de 100 aux tests en laboratoire dès lors que les données de terrain sont satisfaisantes.
Point clé : commencez par résoudre le LCP. L'INP et le CLS sont plus faciles à gérer une fois que le chemin d'accès au contenu principal est optimisé.
Un plan de sauvetage d'une semaine
Jour 1 : extraire les données de terrain, nommer l’élément LCP sur les trois principaux modèles, répertorier tous les scripts tiers en indiquant leur propriétaire. Jours 2 et 3 : déployer uniquement les correctifs LCP liés aux médias et à la découverte. Jour 4 : supprimer ou reporter les scripts tiers les plus problématiques et revérifier l’INP sur un téléphone. Jour 5 : réserver de l’espace pour les éléments non conformes au CLS identifiés lors de l’expérience utilisateur sur le terrain. Jours 6 et 7 : effectuer de nouvelles mesures, documenter ce qui reste à faire et déterminer si le travail restant constitue un obstacle au lancement.
Cette semaine vaut mieux qu'un mois de refactorisations hétéroclites, car chaque jour comporte un indicateur et une boucle de vérification. Si le LCP est toujours au rouge après le troisième jour, ne commencez pas à nettoyer le système de conception. Concentrez-vous sur l'élément LCP jusqu'à ce qu'il évolue.
Point clé : un indicateur par jour, avec une nouvelle mesure, vaut mieux qu'un historique de performances hétéroclite.