Sommaire
De nombreux développeurs s’interrogent, cette fin 2025. Pourquoi Google Search Console indique-t-il un mauvais score de LCP (Largest Contentful Paint) alors que les pages testées individuellement semblent performantes ? Barry Pollard, ingénieur chez Google, a pris le temps d’expliquer sur Bluesky que ce n’est pas un bug, mais une question de mesure.
Comprendre ce que mesure vraiment Search Console
Le LCP, ou Largest Contentful Paint, est l’un des trois Core Web Vitals suivis par Google pour évaluer la rapidité perçue d’une page.
Mais le rapport de Search Console ne repose pas sur des tests de laboratoire : il s’appuie sur des données réelles de navigation (field data) issues du Chrome User Experience Report (CrUX).
Selon Barry Pollard, le chiffre affiché correspond au 75ᵉ centile des performances. C’est-à-dire le temps de chargement que 75 % des sessions réussissent à atteindre ou à dépasser.
Cela signifie que même si toutes les pages testées individuellement paraissent rapides, une minorité de visites lentes suffit à faire chuter la moyenne globale.
Et c’est précisément ce qui se produit sur les sites à forte volumétrie : les pages populaires sont très rapides, mais la longue traîne, plus discrète, ralentit l’ensemble du domaine.
Quand la longue traîne sabote le LCP global
Sur un site e-commerce typique, quelques produits concentrent l’essentiel du trafic. Ces pages sont souvent servies depuis le cache : base de données, CDN, Varnish… Résultat, elles sont très rapides.
Mais des milliers d’autres pages – fiches produits peu vues, catégories profondes ou anciens articles – sont chargées à froid, sans cache disponible. Ces pages “rares” affichent un LCP nettement plus lent, même si elles utilisent le même code, les mêmes images et les mêmes optimisations.
Selon Barry Pollard, c’est exactement ce décalage qui crée la confusion :
« Les caches sont excellents, mais ils peuvent masquer la lenteur réelle du site, celle qu’on observe sur les pages non mises en cache. »
Le problème est purement statistique : dès que cette longue traîne représente plus de 25 % des pages vues, elle fait baisser le 75ᵉ centile global.
Les exemples d’URL que Search Console affiche pour illustrer le rapport, eux, proviennent des pages les plus populaires (et donc les plus rapides). C’est pourquoi le contraste entre les deux semble “illogique”.
Ce n’est pas une erreur. GSC mesure la réalité complète du trafic, pas la vitrine des meilleures pages.
Et cette réalité inclut les pages rarement consultées, celles qui révèlent la vraie vitesse du site hors cache.
Ce que recommande Google
Pour diagnostiquer l’écart, Barry Pollard propose une méthode simple : ajouter un paramètre aléatoire à une URL — par exemple ?test=1234 — puis exécuter un test Lighthouse. Cela force un chargement “non mis en cache”. Comparer les résultats entre la version normale et la version “testée” permet de mesurer la différence entre cache et temps réel.
Si la version non cachée est nettement plus lente, la conclusion est que ton site dépend trop du cache pour maintenir de bonnes performances. L’objectif est d’atteindre un LCP inférieur à 2,5 secondes même sans cache. Le cache doit améliorer la rapidité, pas la masquer.
Pollard enfin souligne que ce phénomène explique aussi les ralentissements observés lors des campagnes publicitaires : les liens avec paramètres UTM sont souvent traités comme des pages inédites et donc non cachées. Il recommande de configurer le CDN pour ignorer ces paramètres et éviter les “cache miss” inutiles.
En résumé
Search Console ne se trompe pas, mais reflète la réalité vécue par l’ensemble des utilisateurs, y compris ceux qui consultent les pages rarement servies. Les caches donnent de bons chiffres en surface, mais les Core Web Vitals mesurent ce que le cache ne montre pas.
La vraie optimisation ne consiste pas à rendre les pages phares encore plus rapides, mais à réduire la dette de performance du long tail, là où les visiteurs — et les algorithmes — perçoivent la lenteur réelle du site.
