Google explique pourquoi la LCP de Search Console n'est pas erronée

Google Search Console (GSC) peut parfois afficher des données contradictoires concernant le Largest Contentful Paint (LCP), un indicateur essentiel des Core Web Vitals. Il n'est pas rare de voir GSC signaler un LCP médiocre pour un site, alors que les URLs exemples fournies semblent toutes avoir de bons scores. Barry Pollard de Google a récemment clarifié ce phénomène, expliquant pourquoi cette apparente incohérence n'est pas une erreur de GSC mais une conséquence de la manière dont les données sont collectées et interprétées.

Comprendre le calcul du LCP dans CrUX

La clé de la compréhension réside dans la façon dont les Core Web Vitals, y compris le LCP, sont mesurés par le Rapport d'Expérience Utilisateur de Chrome (CrUX). CrUX calcule ces métriques en se basant sur le 75e centile des chargements de page. Cela signifie que le score affiché reflète la performance que 75% des pages vues atteignent au minimum. Ce n'est donc pas une moyenne, mais un seuil garantissant qu'une large majorité des utilisateurs bénéficient d'une expérience donnée.

L'énigme des pages populaires et de la longue traîne

Le problème survient particulièrement sur les sites ayant une grande quantité de pages, comme les sites e-commerce. Ces sites ont souvent:

• Des produits très populaires, générant un grand nombre de vues.
• Une "longue traîne" de nombreux produits moins populaires, avec peu de vues.

Les pages populaires sont plus susceptibles d'avoir suffisamment de données CrUX pour être affichées comme exemples dans GSC. Elles sont aussi celles sur lesquelles les développeurs se concentrent naturellement, car elles génèrent le plus de trafic. Cependant, ces pages populaires sont souvent plus rapides grâce à la mise en cache (caches de base de données, Varnish, nœuds CDN).

À l'inverse, les pages de la longue traîne sont beaucoup plus susceptibles de nécessiter un chargement complet, sans bénéficier des caches, ce qui les rend plus lentes. Le piège est que si la longue traîne représente plus de 25% du total des pages vues, leurs performances médiocres, bien que non représentées par les exemples d'URL populaires dans GSC, peuvent faire basculer le score global du 75e centile vers le bas.

En d'autres termes, les caches peuvent masquer une lenteur sous-jacente qui n'est visible que lors des "cache misses", c'est-à-dire quand une page n'est pas servie depuis le cache.

Comment identifier et corriger le problème

Réduire le temps de chargement des pages non mises en cache

Étant donné qu'il existe une limite à la taille des caches et qu'il n'est pas toujours judicieux de pré-cacher des pages peu visitées, la solution principale est de réduire le temps de chargement des pages non mises en cache. Le caching doit être un "plus" et non la seule raison de la rapidité d'un site.

Technique de vérification Lighthouse

Pour tester la performance d'une page non mise en cache, Barry Pollard suggère d'ajouter un paramètre URL aléatoire (ex: ?test=1234) et de lancer un test Lighthouse. Changer la valeur du paramètre à chaque fois forcera généralement le chargement d'une page non mise en cache. Comparez ensuite ce résultat avec un test effectué sur une page mise en cache (en chargeant l'URL normale plusieurs fois). Si la page avec le paramètre est significativement plus lente, vous avez identifié l'écart de performance.

L'objectif idéal est d'obtenir un LCP inférieur à 2,5 secondes même sans cache, afin que les pages populaires (mises en cache) soient encore plus rapides.

Impact des campagnes publicitaires

Il est important de noter que cette problématique peut également affecter les campagnes publicitaires utilisant des paramètres UTM ou similaires, car ces paramètres peuvent faire croire aux CDNs qu'il s'agit de nouvelles pages, contournant ainsi la mise en cache. Il est possible de configurer les CDNs pour qu'ils ignorent ces paramètres, et une nouvelle norme est en cours de développement pour permettre aux pages de spécifier quels paramètres n'ont pas d'importance pour la mise en cache.