Non, Google Search Console n’est pas à côté de la plaque lorsqu’il signale un mauvais LCP global alors que les pages individuelles semblent bonnes. Barry Pollard explique que la différence vient de la façon dont GSC et CrUX mesurent les Core Web Vitals.
CrUX calcule la performance au 75ᵉ percentile des chargements de page, ce qui signifie que si plus de 25 % des pages vues sont plus lentes, le score global baisse. Les pages populaires, souvent présentées comme exemples dans GSC, bénéficient de données suffisantes et sont généralement plus rapides, car elles profitent de caches (base de données, Varnish, CDN). Les pages de la longue traîne (moins fréquentées), qui peuvent représenter plus de 25 % du trafic total, sont souvent non mises en cache et donc plus lentes, même si elles sont techniquement identiques. De plus, les pages peu demandées déclenchent des “cache misses” et doivent être générées depuis zéro, augmentant le LCP.
Voici les conseils de Philip Walton pour améliorer la situation :
- Mesurer la performance sans cache : tester avec un paramètre aléatoire dans l’URL (ex. ?test=1234) pour forcer un chargement non mis en cache dans Lighthouse.
- Comparer avec un test sur la version cachée et réduire l’écart ; viser moins de 2,5 s même sans cache.
- Optimiser le temps de chargement hors cache afin que le cache soit un bonus, pas la seule optimisation.
- Configurer le CDN pour ignorer les paramètres d’URL non pertinents (ex. UTM, gclid) et ainsi conserver l’usage du cache.
- Anticiper le futur standard No Vary Search, qui permettra de définir les paramètres à ignorer pour le caching.
Source : Search Engine Roundtable