Vos Core Web Vitals sont au rouge dans PageSpeed Insights, et le premier conseil qu’on vous donne est de changer de thème. C’est la réponse la plus chère et la plus rarement justifiée. Dans la majorité des cas, les Core Web Vitals d’un site WordPress se redressent avec quelques réglages ciblés et un peu de ménage dans ce qui se charge au démarrage. Ce guide déroule les trois notes une par une, dit où lire les vraies valeurs, et donne les corrections dans l’ordre où elles se font. La dernière section aborde les cas où le thème est réellement en cause, parce qu’ils existent aussi.
En bref
Les Core Web Vitals sont trois mesures : le LCP pour la vitesse d’affichage, l’INP pour la réactivité, le CLS pour la stabilité visuelle.
Google considère comme bons un LCP inférieur ou égal à 2,5 secondes, un INP inférieur ou égal à 200 millisecondes et un CLS inférieur ou égal à 0,1, mesurés au 75e centile.
La note qui compte vient des visites réelles de vos internautes, quand le test lancé depuis votre navigateur ne mesure que votre propre machine.
Les images, les polices et les scripts tiers expliquent la plus grande partie des mauvaises notes sur WordPress, et se corrigent sans refonte.
Obtenir le résumé de cet article par une IA
Ce que mesurent le LCP, l’INP et le CLS
Les Core Web Vitals sont trois indicateurs que Google publie et documente dans sa page de référence sur les signaux web essentiels. Chacun des trois Core Web Vitals couvre un moment différent de l’expérience, et il faut les traiter séparément parce qu’ils ne se corrigent pas avec les mêmes gestes.
Le LCP, pour Largest Contentful Paint, mesure le temps que met le plus gros élément visible à s’afficher. Sur un article, c’est presque toujours l’image de couverture ou le bloc de titre. Le seuil « bon » est fixé à 2,5 secondes. L’INP, pour Interaction to Next Paint, mesure le délai entre le moment où quelqu’un clique et le moment où la page réagit visiblement. Le seuil est de 200 millisecondes. Le CLS, pour Cumulative Layout Shift, mesure les sauts de mise en page : le texte que vous commenciez à lire et qui descend brutalement parce qu’une image ou une bannière vient de se charger au-dessus. Le seuil est de 0,1, et cette valeur n’a pas d’unité, c’est un score.
Un point que beaucoup de débutants ratent : Google ne regarde pas votre moyenne. L’évaluation se fait au 75e centile des chargements de page, séparément sur mobile et sur ordinateur. Autrement dit, il faut que trois visites sur quatre passent sous le seuil. Un site rapide pour vous, sur votre fibre et votre ordinateur récent, peut très bien échouer parce qu’un quart de ses visiteurs est sur un téléphone d’entrée de gamme en 4G moyenne.
Où lire vos vraies notes Core Web Vitals plutôt que le test à blanc
Il existe deux familles de mesures et les confondre fait perdre beaucoup de temps. Les données de terrain viennent du Chrome User Experience Report, que tout le monde abrège en CrUX : ce sont les mesures anonymisées des vrais visiteurs de votre site sous Chrome. Les données de laboratoire viennent d’un test simulé lancé à la demande, dans des conditions figées. Seules les premières comptent pour l’évaluation de Google.
Concrètement, ouvrez PageSpeed Insights et regardez le bloc du haut, celui qui s’intitule « Découvrez ce que vivent vos utilisateurs réels ». Ce bloc est du CrUX. Le grand score coloré sur 100 juste en dessous vient de Lighthouse, donc du laboratoire, et il ne détermine rien du tout côté Google. Un site peut afficher 62 sur 100 en laboratoire et valider ses trois signaux sur le terrain.
La Search Console porte un rapport Signaux web essentiels, qui reprend les Core Web Vitals à partir des mêmes données CrUX, avec l’avantage de grouper vos URL par gabarit. C’est là qu’il faut travailler, parce qu’il vous dit si le problème touche vos articles, vos pages de catégorie ou votre page d’accueil. Attention toutefois au délai : le rapport s’appuie sur une fenêtre glissante de vingt-huit jours, donc une correction déployée aujourd’hui ne se voit pas avant plusieurs semaines. Ce délai décourage beaucoup de gens qui concluent trop vite que leur correction n’a rien donné.
Un dernier piège : un site à faible trafic n’a parfois aucune donnée CrUX, faute d’échantillon suffisant. Dans ce cas, PageSpeed affiche uniquement la partie laboratoire, et la Search Console reste vide. Ce n’est pas un bug. Travaillez alors sur les recommandations Lighthouse en sachant qu’elles sont indicatives, et vérifiez sur un vrai téléphone plutôt que sur votre poste de travail.
Découvrir l’agence SEO Noobies
Les corrections qui tiennent sans toucher au thème
Commencez par les images, parce que c’est presque toujours là que se jouent vos Core Web Vitals, et le LCP en particulier. Une image de couverture servie en pleine résolution, non compressée, dans un format ancien, suffit à faire échouer la note à elle seule. Le trio qui règle la question tient en trois gestes : conversion au format WebP, dimensions réelles adaptées à l’affichage, et attribut de chargement différé sur tout ce qui se trouve sous la ligne de flottaison. C’est exactement le chantier détaillé dans notre guide sur le poids des images WordPress.
Attention à une erreur classique sur ce point : le chargement différé ne doit jamais s’appliquer à l’image de couverture. Différer l’élément qui définit justement votre LCP revient à le retarder volontairement. La plupart des extensions d’optimisation d’images proposent une option pour exclure les premières images de la page, et il faut la cocher.
Le CLS se règle en réservant l’espace avant que le contenu arrive. Chaque image doit porter ses attributs de largeur et de hauteur, ce que WordPress fait automatiquement quand vous passez par la médiathèque, et qu’il ne fait pas quand vous collez du HTML à la main. Les polices personnalisées sont l’autre grande cause de saut : le navigateur affiche d’abord une police de substitution, puis bascule, et tout le bloc bouge. La propriété d’affichage de police en mode « swap » avec une police de repli aux métriques proches supprime l’essentiel du décalage.
L’INP est le signal le plus lié aux extensions. Chaque script qui tourne pendant que le visiteur clique retarde la réponse. Faites l’inventaire de ce qui charge sur votre site : bandeau de consentement, chat, pixels publicitaires, carrousels, curseurs animés, compteurs. Désactivez tout ce dont vous ne vous servez plus, et vérifiez que le reste ne se charge que là où c’est utile. Une extension désactivée dans l’administration continue parfois de charger ses fichiers côté visiteur, ce qui explique des ralentissements incompréhensibles sur des sites pourtant nettoyés. Notre article sur les accès cachés des extensions WordPress détaille comment repérer ce genre de résidu.
Ajoutez ensuite une couche de cache et de concaténation. Un cache de pages sert une version déjà construite au lieu de relancer la base de données à chaque visite. La concaténation regroupe les fichiers de style et de script pour réduire le nombre d’allers-retours. Ces deux réglages se posent en quelques minutes avec une extension d’optimisation, et ils déplacent souvent le LCP de plusieurs centaines de millisecondes. Testez toujours l’affichage après activation : la concaténation agressive casse parfois la mise en page, et il faut alors exclure un fichier précis.
Vérifiez enfin vos redirections. Une chaîne de redirections ajoute un aller-retour réseau complet avant même que la page commence à se charger, et ces chaînes s’accumulent silencieusement au fil des changements d’URL. Le sujet est traité en détail dans notre guide sur la redirection 301 sur WordPress.
Les cas où le thème est réellement en cause
Il faut être honnête, la refonte est parfois la bonne réponse. Le cas le plus net est celui des constructeurs de pages qui produisent un empilement de conteneurs imbriqués et chargent leur propre bibliothèque de styles sur chaque page, y compris celles qui n’utilisent aucun de leurs blocs. Sur ces sites, vous pouvez optimiser les images pendant des heures, le socle reste lourd.
Le deuxième cas est celui des thèmes vendus avec une démonstration très fournie : diaporamas, animations au défilement, compteurs, arrière-plans vidéo. Ces éléments sont rarement désactivables proprement, et ils pèsent sur l’INP en permanence. Le troisième cas, plus rare, concerne les thèmes qui chargent des polices depuis un service externe sans possibilité de les héberger localement.
Le test qui tranche est simple à mener. Activez un thème par défaut de WordPress sur une copie de développement, sans rien changer d’autre, et relancez la mesure. Si les Core Web Vitals restent mauvais, le thème n’était pas le problème et il faut chercher du côté de l’hébergement ou des extensions. Si elles s’améliorent nettement, vous avez votre réponse, et vous savez au moins que la dépense se justifie. Faire ce test avant de payer une refonte évite de refaire un site qui n’en avait pas besoin.
Reste l’hébergement, qu’on oublie souvent alors qu’il conditionne tout le reste. Un serveur mutualisé saturé ajoute un délai avant même l’envoi du premier octet, et aucune optimisation côté page ne rattrape ce retard. Si votre temps de réponse serveur dépasse régulièrement les 600 millisecondes en mesure de terrain, regardez de ce côté avant d’ouvrir le moindre fichier de thème.
Continuez de progresser sur SEO Noobies.
