« J’ai 45 sur PageSpeed, comment monter à 90 ? » C’est presque toujours ainsi que la question arrive. Et c’est rarement la bonne, parce que le score n’est pas l’objectif : ce sont vos visiteurs réels, sur leurs appareils réels, qui comptent.
Les Core Web Vitals sont trois mesures qui tentent de traduire l’expérience réellement perçue : à quelle vitesse le contenu principal apparaît, à quelle vitesse le site répond quand on interagit, et si la mise en page reste stable. Google les utilise comme signal, mais leur intérêt premier est ailleurs : un site qui va mieux sur ces trois points vend plus.
Voici ce qu’elles mesurent exactement, et ce qui les dégrade sur WordPress.
Réponse rapide
Trois mesures, trois seuils : LCP (affichage du plus grand élément visible) doit rester sous 2,5 s, INP (réactivité aux interactions) sous 200 ms, CLS (stabilité visuelle) sous 0,1. Ce qui compte, ce sont les données terrain issues de vos visiteurs réels, pas le score d’un test ponctuel. Sur WordPress, les causes les plus fréquentes sont : une image de bandeau trop lourde ou chargée tardivement (LCP), un excès de JavaScript provenant des extensions et des scripts tiers (INP), et des images ou bandeaux sans dimensions réservées (CLS).
Ce que mesure chaque indicateur
LCP — le plus grand contenu affiché
Le temps au bout duquel le plus grand élément visible de l’écran apparaît : en général l’image de bandeau, la photo principale d’un produit, ou un gros bloc de texte. Seuil : 2,5 secondes.
C’est l’indicateur qui reflète le mieux la sensation de « site lent ». Ses causes sont presque toujours : un temps de réponse serveur élevé, une image trop lourde ou dans un mauvais format, ou une ressource bloquante qui retarde l’affichage.
INP — la réactivité aux interactions
Le délai entre l’action d’un visiteur — clic, appui, saisie — et la réponse visible de la page. Seuil : 200 millisecondes.
Cet indicateur a remplacé l’ancienne mesure du premier délai d’entrée, et il est plus exigeant : il observe toutes les interactions de la visite, pas seulement la première. Sur WordPress, il se dégrade quand trop de JavaScript s’exécute — extensions, suivi analytique, chat, sliders, constructeurs de pages.
CLS — la stabilité visuelle
Mesure les déplacements inattendus du contenu pendant le chargement. Seuil : 0,1.
C’est l’expérience du bouton sur lequel on s’apprête à cliquer et qui se dérobe parce qu’une bannière vient de s’insérer au-dessus. Causes classiques : images sans dimensions déclarées, polices qui remplacent une police de substitution, bandeaux de consentement insérés en haut de page, publicités.
Données terrain contre données de laboratoire
C’est la distinction la plus importante, et la plus souvent ignorée.
Les données de laboratoire sont produites par un test ponctuel, sur une machine et une connexion simulées. Utiles pour diagnostiquer et comparer avant/après. Mais un score de laboratoire varie énormément d’un test à l’autre.
Les données terrain sont collectées auprès des visiteurs réels de votre site, sur leurs vrais appareils et leurs vraies connexions. C’est ce que Google utilise comme signal, et c’est ce qui reflète l’expérience réelle de vos clients.
Conséquence pratique : un site peut afficher un mauvais score de laboratoire et de bonnes données terrain — par exemple si vos visiteurs sont majoritairement sur ordinateur avec une bonne connexion. Et l’inverse existe aussi.
Décidez toujours sur les données terrain. La Search Console les présente par groupe de pages, ce qui est le plus exploitable : cela vous dit quels gabarits poser problème, pas seulement quelle page d’exemple.
Les causes les plus fréquentes sur WordPress
L’image de bandeau
Premier facteur de mauvais LCP. Une photo de 2 Mo servie en pleine largeur, parfois au format d’origine de l’appareil photo. À corriger : dimensions adaptées, format moderne, compression, et surtout ne pas différer le chargement de l’image visible à l’ouverture — beaucoup d’extensions de performance appliquent le chargement différé partout, ce qui retarde précisément l’élément qui définit le LCP.
Le temps de réponse serveur
Si le serveur met une seconde à commencer à répondre, votre LCP ne descendra jamais sous cette limite. Hébergement mutualisé saturé, absence de cache pleine page, base de données encombrée, requêtes lentes. C’est le plancher de toute optimisation.
L’accumulation de JavaScript
Chaque extension ajoute son script, souvent sur toutes les pages, y compris celles où elle ne sert à rien. Un formulaire de contact qui charge sa bibliothèque sur la page d’accueil, un slider présent sur tout le site pour une seule page. C’est le principal facteur de mauvais INP.
Les constructeurs de pages
Ils génèrent un balisage profond, beaucoup de CSS et de JavaScript, et rendent difficile tout allègement. Ce n’est pas une fatalité — un site construit sobrement avec un constructeur peut être rapide — mais le risque est réel, et il augmente avec le nombre de blocs et d’effets. J’en parle plus en détail dans l’article consacré aux sites lents sous constructeur de pages.
Les scripts tiers
Chat, analytique, cartes de fidélité, avis, publicités : chacun est un script externe dont vous ne maîtrisez ni la taille ni la disponibilité. Un outil tiers lent ralentit votre site, et vous n’y pouvez rien d’autre que le retirer ou le charger différemment.
Les polices
Une police chargée depuis un serveur externe ajoute une connexion et un délai. Hébergez vos polices, limitez-vous à deux familles, et déclarez un comportement d’affichage qui évite le texte invisible pendant le chargement.
L’ordre dans lequel corriger
- Le temps de réponse serveur. C’est le plancher : tant qu’il est mauvais, rien d’autre ne suffira. Cache pleine page, hébergement correct, base de données nettoyée.
- L’image du LCP. Identifiez-la précisément — les outils de mesure vous la désignent — puis redimensionnez, compressez, et excluez-la du chargement différé.
- Le JavaScript inutile. Listez les extensions actives, vérifiez lesquelles chargent quelque chose sur toutes les pages, et limitez-les aux pages concernées.
- Les dimensions réservées. Largeur et hauteur déclarées sur toutes les images, espace réservé pour les bandeaux et les blocs insérés dynamiquement.
- Les scripts tiers. Chaque outil doit justifier son coût. Un chat utilisé une fois par semaine ne vaut pas de ralentir toutes vos pages.
- Les polices. Auto-hébergement, nombre limité, préchargement de la police utilisée au-dessus de la ligne de flottaison.
Cet ordre suit l’impact décroissant. Les deux premiers points règlent souvent l’essentiel du problème.
Les fausses bonnes idées
Empiler les extensions de performance. Deux extensions de cache qui se marchent dessus produisent des résultats imprévisibles et parfois des pages cassées. Une seule, bien configurée.
Tout différer. Différer le chargement de toutes les images, y compris celle du bandeau, dégrade le LCP au lieu de l’améliorer. Différer tout le JavaScript casse souvent des fonctionnalités.
Courir après le score de 100. Le gain entre 85 et 95 est marginal pour vos visiteurs, et coûte beaucoup plus cher que celui entre 40 et 70. Arrêtez-vous quand les données terrain passent dans le vert.
Optimiser sans mesurer avant. Sans point de comparaison, vous ne saurez jamais si votre intervention a servi — ni si elle a dégradé autre chose.
Négliger le mobile. Les données terrain sont généralement bien moins bonnes sur mobile. Et c’est souvent là que se trouve la majorité de votre trafic.
Checklist
- Regarder les données terrain dans la Search Console, par groupe de pages
- Mesurer le temps de réponse serveur avant toute autre optimisation
- Identifier précisément l’élément qui définit le LCP
- Exclure l’image visible à l’ouverture du chargement différé
- Déclarer largeur et hauteur sur toutes les images
- Réserver l’espace des bandeaux insérés dynamiquement
- Lister les extensions qui chargent des scripts sur toutes les pages
- Auto-héberger les polices et limiter leur nombre
- Mesurer avant et après chaque intervention
Questions fréquentes
Les Core Web Vitals influencent-ils vraiment le référencement ?
Ils sont un signal parmi beaucoup d’autres, et pas le plus déterminant : un contenu pertinent sur un site moyennement rapide se positionnera mieux qu’un contenu faible sur un site très rapide. Leur véritable intérêt est ailleurs : un site plus rapide convertit mieux, et cela se mesure directement dans vos ventes.
Mon score varie d’un test à l’autre. C’est normal ?
Oui, c’est inhérent aux tests de laboratoire : la machine, le réseau simulé et la charge du moment varient. Ne tirez pas de conclusion d’un test isolé. Les données terrain, agrégées sur plusieurs semaines, sont bien plus stables.
Une extension de cache suffit-elle ?
Elle traite bien le temps de réponse serveur, ce qui est déjà beaucoup. Mais elle ne réduira pas le poids de vos images, ne supprimera pas le JavaScript inutile et ne corrigera pas les décalages de mise en page. C’est une brique, pas une solution complète.
Faut-il changer de thème ?
Parfois, mais c’est une décision lourde à ne prendre qu’après avoir mesuré. Beaucoup de thèmes réputés lents le deviennent surtout par la façon dont on les utilise. Commencez par mesurer ce que coûte réellement votre thème, à extensions désactivées, sur une préproduction.
Combien de temps pour voir l’effet dans la Search Console ?
Les données terrain sont agrégées sur une fenêtre de 28 jours. Comptez donc plusieurs semaines avant que l’amélioration n’y soit pleinement visible, même si vos visiteurs en bénéficient immédiatement.