Pourquoi Google Search Console LCP n'est pas faux, selon Google

Barry Pollard de Google a fait une longue explication sur Bluesky sur les raisons pour lesquelles Google Search Console dit qu'un LCP est mauvais mais les URL individuelles sont bien. Je ne veux pas gâcher, donc je vais copier ce que Barry a écrit.

Voici ce qu'il a écrit sur plusieurs articles sur Bluesky:

Core Web vitals Mystery pour vous:

Pourquoi Google Search Console est-il même que mon LCP est mauvais, mais chaque exemple URL a un bon LCP?

Je vois des développeurs demander: comment cela peut-il arriver? GSC est-il faux? (Je suis prêt à parier que ce n'est pas le cas!) Que pouvez-vous faire à ce sujet?

Ceci est certes déroutant, alors plongeons-nous …

Il est d'abord important de comprendre comment ce rapport et Crux mesurent les vitaux du Web de base, car une fois que vous l'avez fait, il est plus compréhensible, mais laisse toujours la question de ce que vous pouvez faire à ce sujet (nous y reviendrons).

Le problème est similaire à ce fil précédent:

« Comment est-il possible pour Crux de dire que 90% des charges de page sont bonnes, et la console de recherche Google pour dire que seulement 50% des URL sont bonnes. Ce qui est juste? »

C'est une question que j'obtiens à propos de Core Web Vitals et j'avoue que c'est déroutant, mais la vérité est que les deux sont correctes car ce sont des mesures différentes …

1/5 🧵

– Barry Pollard (@ Tunenetheweb.com) 19 août 2025 à 6h32

Crux Mesures Page Charges et le numéro de Vitals Web de base est le 75e centile de ces charges de page.

C'est une façon sophistiquée de dire: « Le score que la plupart des pages vues obtiennent au moins » – le whee « le plus » est de 75%.

Philip Walton le couvre davantage dans cette vidéo:

https://www.youtube.com/watch?v=fwoi9dxmpdk

Pour un site de commerce électronique avec beaucoup de produits, vous aurez des produits très populaires (avec beaucoup de pages vues!), Puis une longue et longue queue de nombreuses pages moins populaires (avec un petit nombre de pages vues).

Le problème se pose lorsque la longue queue s'ajoute à plus de 25% de vos pages vues.

Les plus populaires sont plus susceptibles d'avoir des données de nœud de niveau de page (nous ne sommes que des données lorsque nous franchissons un seuil non publique), il en est de quoi ceux qui sont plus susceptibles d'être montrés comme des exemples dans GSC à cause de cela.

Ce sont aussi ceux sur lesquels vous devriez probablement vous concentrer – ce sont ceux qui obtiennent le trafic!

Mais les pages populaires ont un autre biais intéressant: ils sont souvent plus rapides!

Pourquoi? Parce qu'ils sont souvent mis en cache. Dans les caches DB, dans les caches de vernis, et surtout aux nœuds CDN Edge.

Les pages à longue queue sont beaucoup plus susceptibles de nécessiter une charge pleine de page, de sauter toutes ces caches, et seront donc plus lentes.

Cela est vrai même si les pages sont construites sur la même technologie et sont optimisées de la même manière avec toutes les mêmes techniques de codage et les images optimisées … etc.

Les caches sont super! Mais ils peuvent masquer la lenteur qui n'est vu que pour les « manquements de cache ».

Et c'est souvent pourquoi vous voyez cela en GSC.

Alors comment réparer?

Il y aura toujours une limite aux tailles de cache et aux caches d'amorçage pour les pages peu visitées n'a pas beaucoup de sens, vous devez donc réduire le temps de chargement des pages non achetées.

La mise en cache devrait être une « cerise sur le dessus » pour augmenter la vitesse, plutôt que la seule raison pour laquelle vous avez un site rapide.

Une façon dont j'aime vérifier, c'est ajouter un paramètre d'URL aléatoire à une URL (par exemple? Test = 1234), puis réinstaller un test de phare en modifiant la valeur à chaque fois. Habituellement, cela se traduit par le retrait d'une page non achetée.

Comparez cela à une page en cache (en exécutant l'URL normale à quelques reprises).

Si c'est beaucoup plus lent, vous comprenez maintenant la différence entre votre cache et non achetée et pouvez commencer à réfléchir à des moyens d'améliorer cela.

Idéalement, vous l'obtenez en moins de 2,5 secondes même sans cache, et vos pages populaires (mises en cache) sont tout simplement encore plus rapides!

Soit dit en passant, cela peut également être la raison pour laquelle les campagnes publicitaires (avec des paramètres UTM aléatoires et similaires) peuvent également être plus lents.

Vous pouvez configurer les CDN pour les ignorer et ne pas les traiter comme de nouvelles pages. Il existe également une norme à venir pour permettre à une page de spécifier quels paramètres n'ont pas d'importance:

Ceci est cool et attendait que la recherche sans vol d'échappement d'échapper aux règles de spéculation (où cela a été initialement démarré) dans le cas d'utilisation plus général.

Cela vous permet de dire que certains paramètres d'URL côté client (par exemple GCLID ou autres paramètres analytiques) peuvent être ignorés tout en utilisant la ressource à partir du cache.

[image or embed]

– Barry Pollard (@ Tunenetheweb.com) 26 septembre 2025 à 11 h 57

Discussion du forum à Bluesky.