Depuis l’annonce initiale, une forme de panique commerciale s’est installée autour de la mise à jour Page Experience : agences et éditeurs d’extensions promettent des chutes de classement massives pour qui n’atteindrait pas un score Lighthouse parfait. Il est temps de séparer ce que Google a réellement communiqué de ce qui relève de l’argument de vente.
Ce que regroupe réellement Page Experience
Le signal Page Experience n’est pas une nouveauté isolée : il combine les trois Core Web Vitals (LCP, FID, CLS, annoncés en mai 2020) à des signaux déjà pris en compte depuis plusieurs années : compatibilité mobile, navigation en HTTPS, absence d’interstitiels intrusifs, et sécurité de navigation (absence de contenu trompeur ou de logiciel malveillant). Pour un site WordPress déjà en HTTPS et responsive, la nouveauté se limite essentiellement à l’ajout des Core Web Vitals dans cette équation déjà existante.
Ce qui relève du mythe
Plusieurs affirmations circulent sans fondement dans la documentation officielle de Google :
- « Un mauvais score Page Experience fait disparaître une page des résultats » : faux. C’est un signal de classement parmi des centaines d’autres, pas un critère éliminatoire.
- « Il faut un score Lighthouse de 100 pour ne pas être pénalisé » : faux. Les seuils communiqués par Google pour les Core Web Vitals se situent à des niveaux atteignables sans viser la perfection (LCP sous 2,5 s, CLS sous 0,1).
- « Le contenu compte moins que la technique depuis cette mise à jour » : faux, et Google l’a explicitement démenti. La pertinence du contenu reste le facteur dominant.
Ce qui compte vraiment pour un site WordPress
Le déploiement se fait progressivement sur plusieurs mois, ce qui laisse le temps d’agir sans précipitation. Trois priorités concrètes ressortent pour la majorité des sites WordPress :
Le LCP dépend souvent d’une seule image
Sur un site WordPress classique, le Largest Contentful Paint correspond très souvent à l’image principale de la page (bannière, image à la une). Vérifier qu’elle n’est pas chargée en loading="lazy", qu’elle est correctement dimensionnée et servie dans un format performant couvre la majorité des cas de LCP dégradé.
Le CLS vient rarement du contenu éditorial
Les décalages de mise en page proviennent le plus souvent d’éléments tiers : bannières de consentement qui s’affichent après coup, publicités sans espace réservé, polices web qui changent la taille du texte à leur chargement. Un audit CLS doit regarder en priorité ces éléments avant le contenu du thème lui-même.
Le FID dépend du JavaScript exécuté au démarrage
Le First Input Delay mesure le temps avant que la page ne réponde à la première interaction. Sur WordPress, les extensions qui exécutent du JavaScript lourd dès le chargement (carrousels, animations complexes) sont les premières suspectes en cas de FID élevé.
Comment vérifier sa situation sans paniquer
La Search Console propose un rapport dédié aux Core Web Vitals, basé sur des données réelles de visiteurs (CrUX), pas seulement sur un test de laboratoire. C’est la première source à consulter, car elle reflète l’expérience réelle plutôt qu’un scénario simulé.
Un score parfait en laboratoire ne garantit rien si les visiteurs réels, sur des connexions et des appareils variés, vivent une expérience différente.
Pour aller plus loin
La bonne réaction face à cette mise à jour n’est ni la panique, ni l’indifférence. C’est l’occasion de traiter des points qui méritaient déjà de l’attention avant même que Google ne les mette en avant : un LCP correctement optimisé, une mise en page stable, une interactivité rapide profitent d’abord aux visiteurs, le classement n’en est qu’une conséquence secondaire.
