Pourquoi votre site est-il lent ?

Que mesurent les trois indicateurs ?

Google publie trois niveaux pour chacun : bon, à améliorer et mauvais. Commencez par déterminer quel indicateur sort de la plage jugée bonne. Chacun oriente le diagnostic vers un problème différent.

Le Largest Contentful Paint (LCP) mesure le moment où la plus grande image, le plus grand bloc de texte ou la plus grande vidéo visible apparaît à l’écran. Le résultat est bon jusqu’à 2,5 secondes incluses. Au-delà de 2,5 et jusqu’à 4 secondes incluses, une amélioration est nécessaire ; au-delà de 4 secondes, le résultat est mauvais.

Le LCP se décompose en quatre parties : le délai avant le premier octet (TTFB), l’attente avant le début du téléchargement de la ressource nécessaire, le téléchargement lui-même et le délai avant son affichage. Un texte utilisant une police système peut ne nécessiter aucune ressource distincte à télécharger. Réduire une image ne résoudra pas tout si le navigateur attend toujours du JavaScript avant de l’afficher.

L’Interaction to Next Paint (INP) mesure la réactivité à des interactions comme un clic, un toucher de l’écran ou une frappe au clavier, jusqu’à la prochaine mise à jour de l’affichage. Le résultat est bon jusqu’à 200 millisecondes incluses. Au-delà de 200 et jusqu’à 500 millisecondes incluses, une amélioration est nécessaire ; au-delà de 500 millisecondes, la réactivité est mauvaise.

Le Cumulative Layout Shift (CLS) mesure les déplacements inattendus des éléments de la page. C’est un score sans unité, et non une durée en secondes. Des déplacements peuvent aussi se produire après le chargement initial. Le résultat est bon jusqu’à 0,1 inclus. Au-delà de 0,1 et jusqu’à 0,25 inclus, une amélioration est nécessaire ; au-delà de 0,25, la stabilité visuelle est mauvaise.

L’évaluation en conditions réelles utilise le 75e percentile, séparément pour les mobiles et les ordinateurs. Si ce résultat se situe dans la plage jugée bonne, au moins 75 % des visites mesurées respectent le seuil correspondant. Un test rapide sur votre ordinateur ne décrit pas l’expérience de tous vos visiteurs.

Quel rapport avec le classement dans Google ?

Google utilise les Core Web Vitals dans ses systèmes de classement. De bons résultats ne garantissent toutefois pas une place en tête. Le contenu doit rester utile et pertinent pour la recherche ; aucun indicateur ne détermine à lui seul la position.

Corrigez les problèmes mesurés parce qu’ils gênent l’utilisation de la page. Une amélioration du LCP, de l’INP ou du CLS ne permet pas de promettre une position précise, une hausse de trafic ou davantage de demandes de contact.

D’où peuvent venir les retards ?

Quatre familles de causes décrites dans la documentation de web.dev constituent un point de départ. Examinez-les en fonction de la page et de l’indicateur concernés.

• Des images lourdes. Le fichier peut dépasser la taille nécessaire à l’écran, ou son téléchargement commencer trop tard. Vérifiez les dimensions, la compression, les formats WebP ou AVIF et le moment où le navigateur découvre la ressource. Un CDN d’images peut convenir à certains cas ; ce n’est pas une correction obligatoire pour tous les sites.
• Un délai élevé avant le premier octet. Le TTFB comprend l’attente avant l’arrivée des premières données. Le serveur, le réseau, les redirections et le cache peuvent tous intervenir. Vérifiez aussi si des paramètres d’URL, tels que utm_, empêchent une bonne mise en cache. Un TTFB élevé laisse moins de temps aux autres parties du LCP.
• Trop de travail sur le thread principal. De longues tâches JavaScript peuvent retarder la réponse à une action. Gardez dans le gestionnaire ce qui est nécessaire à la prochaine mise à jour de l’affichage et reportez les autres opérations à des tâches ultérieures lorsque le code le permet.
• Des polices qui retardent le texte ou déplacent la mise en page. Vérifiez les requêtes, le moment du chargement, la police de remplacement et font-display. WOFF2 et des sous-ensembles contenant les caractères nécessaires peuvent réduire les données transférées. Chaque sous-ensemble doit conserver les caractères réellement utilisés par les langues du site.

Données réelles ou test en laboratoire ?

Les données de terrain décrivent l’utilisation sur différents appareils, réseaux et interactions. PageSpeed Insights peut afficher ces données issues du Chrome User Experience Report (CrUX), lorsqu’elles sont disponibles. Vérifiez si elles concernent l’URL précise ou l’origine entière du site. Un volume insuffisant de données pour une URL ne constitue ni un bon ni un mauvais résultat.

Un test en laboratoire aide à reproduire un problème et à vérifier une modification. Le test habituel de chargement de Lighthouse mesure le LCP et le CLS, mais ne mesure pas l’INP sans interaction. Son Total Blocking Time (TBT) peut aider à diagnostiquer un problème de réactivité ; ce n’est pas un INP mesuré auprès de visiteurs réels. Notez le type de données avec le résultat.

Questions

Sources

• web.dev : Largest Contentful Paint
• web.dev : Interaction to Next Paint
• web.dev : Cumulative Layout Shift
• web.dev : optimiser le LCP
• web.dev : optimiser l’INP
• web.dev : bonnes pratiques pour les polices
• web.dev : mesurer les Web Vitals
• Google : Core Web Vitals et résultats de recherche
• Google : expérience sur la page

Pour poursuivre

• Vérifier les liens cassés
• Examiner le site avant une campagne publicitaire