Barry Pollard, défenseur des performances Web de Google Chrome, a expliqué comment trouver les véritables causes d'un mauvais score de peinture de contenu le plus bas et comment y remédier.
La plus grande peinture de contenu (LCP)
LCP est une métrique Web Vitals de base qui mesure le temps nécessaire pour que le plus grand élément de contenu s'affiche dans la fenêtre d'affichage des visiteurs d'un site (la partie qu'un utilisateur voit dans un navigateur). Un élément de contenu peut être une image ou un texte.
Pour LCP, les éléments de contenu les plus grands sont des éléments HTML au niveau bloc qui occupent le plus grand espace horizontalement, comme les paragraphes.
titres (H1 – H6) et images (essentiellement la plupart des éléments HTML qui occupent une grande quantité d’espace horizontal).
1. Sachez quelles données vous consultez
Barry Pollard a écrit qu'une erreur courante que commettent les éditeurs et les référenceurs après avoir vu que PageSpeed Insights (PSI) signale une page avec un mauvais score LCP est de déboguer le problème dans l'outil Lighthouse ou via les outils de développement Chrome.
Pollard recommande de rester sur PSI car il offre plusieurs indices pour comprendre les problèmes à l'origine de mauvaises performances du LCP.
Il est important de comprendre quelles données PSI vous fournit, en particulier les données dérivées du rapport d'expérience utilisateur Chrome (CrUX), qui proviennent des scores anonymisés des visiteurs Chrome. Il en existe deux sortes :
- Données au niveau de l'URL
- Données au niveau de l'origine
Les scores au niveau de l'URL sont ceux de la page spécifique en cours de débogage. Les données au niveau de l'origine sont des scores agrégés de l'ensemble du site Web.
PSI affichera les données au niveau de l'URL s'il y a eu suffisamment de trafic mesuré vers une URL. Sinon, il affichera les données de niveau d'origine (le score agrégé à l'échelle du site).
2. Examinez le score TTFB
Barry recommande de jeter un œil au score TTFB (Time to First Byte) car, selon ses mots, « TTFB est la première chose qui arrive à votre page ».
Un octet est la plus petite unité de données numériques permettant de représenter du texte, des chiffres ou du multimédia. TTFB vous indique combien de temps il a fallu à un serveur pour répondre avec le premier octet, révélant si le temps de réponse du serveur est une raison des mauvaises performances du LCP.
Il dit que concentrer les efforts sur l'optimisation d'une page Web ne résoudra jamais un problème enraciné dans une mauvaise plaie TTFB.
Barry Pollard écrit :
« Un TTFB lent signifie essentiellement 1 des 2 choses :
1) L'envoi d'une requête à votre serveur prend trop de temps
2) Votre serveur met trop de temps à répondreMais de quoi il s'agit (et pourquoi !) peut être difficile à comprendre et il existe plusieurs raisons possibles pour chacune de ces catégories.
Barry a poursuivi sa présentation du débogage LCP avec des tests spécifiques décrits ci-dessous.
3. Comparez le TTFB avec le test Lighthouse Lab
Pollard recommande de tester avec Lighthouse Lab Tests, en particulier l'audit « Temps de réponse initial du serveur ». L'objectif est de vérifier si le problème TTFB est reproductible afin d'éliminer la possibilité que les valeurs PSI soient un hasard.
Les résultats de laboratoire sont synthétiques et ne sont pas basés sur les visites réelles des utilisateurs. Synthétiques signifie qu'ils sont simulés par un algorithme basé sur une visite déclenchée par un test Lighthouse.
Les tests synthétiques sont utiles car ils sont reproductibles et permettent à un utilisateur d'isoler une cause spécifique d'un problème.
Si le test Lighthouse Lab ne reproduit pas le problème, cela signifie que le problème ne vient pas du serveur.
Il a conseillé :
« L’essentiel ici est de vérifier si le TTFB lent est reproductible. Alors faites défiler vers le bas et voyez si le test du laboratoire Lighthouse correspondait à ce lent TTFB d'utilisateur réel lorsqu'il a testé la page. Recherchez l’audit « Temps de réponse initial du serveur ».
Dans ce cas, c'était beaucoup plus rapide – c'est intéressant !
4. Conseil d'expert : comment vérifier si CDN cache un problème
Barry a donné un excellent conseil sur les réseaux de diffusion de contenu (CDN), comme Cloudflare. Un CDN conservera une copie d'une page Web dans les centres de données, ce qui accélérera la livraison des pages Web mais masquera également tout problème sous-jacent au niveau du serveur.
Le CDN ne conserve pas de copie dans tous les centres de données du monde. Lorsqu'un utilisateur demande une page Web, le CDN récupère cette page Web sur le serveur, puis en fait une copie sur le serveur le plus proche de ces utilisateurs. Ainsi, cette première récupération est toujours plus lente, mais si le serveur est lent au début, cette première récupération sera encore plus lente que la livraison de la page Web directement à partir du serveur.
Barry suggère les astuces suivantes pour contourner le cache du CDN :
- Testez la page lente en ajoutant un paramètre d'URL (comme ajouter « ?XYZ » à la fin de l'URL).
- Testez une page qui n’est pas couramment demandée.
Il suggère également un outil qui peut être utilisé pour tester des pays spécifiques :
« Vous pouvez également vérifier si ce sont particulièrement les pays qui sont lents, en particulier si vous n'utilisez pas de CDN, avec CrUX et @alekseykulikov.bsky.social. Treo de est l'un des meilleurs outils pour ce faire.
Vous pouvez exécuter un test gratuit ici : treo.sh/sitespeed, faire défiler jusqu'à la carte et passer à TTFB.
Si certains pays ont des TTFB lents, vérifiez la quantité de trafic provenant de ces pays. Pour des raisons de confidentialité, CrUX ne vous montre pas les volumes de trafic (sauf s'il a suffisamment de trafic à afficher), vous devrez donc consulter vos analyses pour cela.
Concernant la lenteur des connexions depuis des zones géographiques spécifiques, il est utile de comprendre que la lenteur des performances dans certains pays en développement pourrait être due à la popularité des appareils mobiles bas de gamme. Et il convient de répéter que CrUX ne révèle pas de quels pays proviennent les mauvais scores, ce qui signifie faire appel à Analytics pour aider à identifier les pays à trafic lent.
5. Corrigez ce qui peut être répété
Barry a terminé sa discussion en indiquant qu'un problème ne peut être résolu qu'une fois qu'il a été vérifié qu'il est reproductible.
Il a conseillé :
« Pour les problèmes de serveur, le serveur est-il sous-alimenté ?
Ou le code est tout simplement trop complexe/inefficace ?
Ou une base de données nécessitant un réglage ?
Pour les connexions lentes depuis certains endroits, avez-vous besoin d’un CDN ?
Ou cherchez pourquoi tant de trafic à partir de là (campagne publicitaire ?)
Si aucun de ces éléments ne se démarque, cela pourrait être dû à des redirections, notamment provenant de publicités. Ils peuvent ajouter environ 0,5 seconde au TTFB – par redirection !
Essayez de réduire les redirections autant que possible :
– Utilisez l’URL finale correcte pour éviter d’avoir à rediriger vers www ou https.
– Évitez plusieurs services de raccourcissement d’URL.
Points à retenir : Comment optimiser la plus grande peinture de contenu
Barry Pollard de Google Chrome a proposé cinq conseils importants.
1. Les données PageSpeed Insights (PSI) peuvent offrir des indices pour déboguer les problèmes LCP, ainsi que d'autres nuances abordées dans cet article qui aident à donner un sens aux données.
2. Les données PSI TTFB (Time to First Byte) peuvent indiquer pourquoi une page a de mauvais scores LCP.
3. Les tests de laboratoire Lighthouse sont utiles pour le débogage car les résultats sont reproductibles. Des résultats reproductibles sont essentiels pour identifier avec précision la source d’un problème LCP, ce qui permet ensuite d’appliquer les bonnes solutions.
4. Les CDN peuvent masquer la véritable cause des problèmes LCP. Utilisez l'astuce de Barry décrite ci-dessus pour contourner le CDN et récupérer un véritable score de laboratoire qui peut être utile pour le débogage.
5. Barry a énuméré six causes potentielles de mauvais scores LCP :
- Performances du serveur
- redirections
- code
- base de données
- Connexions lentes spécifiques à la situation géographique
- Connexions lentes à partir de zones spécifiques dues à des raisons spécifiques telles que les campagnes publicitaires.
Lisez le message de Barry sur Bluesky :
Quelques personnes m'ont contacté récemment pour me demander de l'aide concernant des problèmes LCP.
