Les Core Web Vitals occupent une place étrange dans les conversations sur le référencement : tout le monde en parle, beaucoup de sites affichent un rapport rouge, et presque personne ne sait quel chiffre est réellement pris en compte. Ce n’est pourtant pas un sujet compliqué — c’est un sujet mal raconté.
Voici ce que ces indicateurs mesurent, ce que Google en fait, et l’ordre dans lequel nous les traitons sur un site WordPress. Sans promesse de score parfait : nous allons justement expliquer pourquoi c’est une mauvaise cible.
Trois métriques, trois seuils
| Métrique | Ce qu’elle mesure | Bon |
|---|---|---|
| LCP — Largest Contentful Paint | Le temps au bout duquel le plus gros élément visible (image, titre, bloc de texte) est affiché | ≤ 2,5 s |
| INP — Interaction to Next Paint | La réactivité : le délai entre une interaction du visiteur et le moment où l’écran répond | ≤ 200 ms |
| CLS — Cumulative Layout Shift | La stabilité visuelle : de combien la mise en page bouge pendant le chargement | ≤ 0,1 |
L’INP a remplacé le FID en mars 2024, et c’est un durcissement : le FID ne mesurait que le délai avant la première réaction, l’INP regarde l’ensemble des interactions de la visite. Un site qui passait de justesse avec l’ancien indicateur peut échouer avec le nouveau, sans que rien n’ait changé dans le code.
Le chiffre qui compte n’est pas celui de votre rapport PageSpeed
C’est le malentendu principal. Le score sur 100 que renvoie Lighthouse est une mesure de laboratoire : une seule visite, simulée, sur une machine et une connexion théoriques. Il est utile pour diagnostiquer, il varie d’un test à l’autre, et ce n’est pas lui que Google utilise.
Les Core Web Vitals sont évalués sur des données de terrain : les visites réelles des utilisateurs de Chrome, agrégées sur 28 jours, et lues au 75e centile. Autrement dit : trois visiteurs sur quatre doivent être sous le seuil. C’est une exigence différente d’un test unitaire réussi — un site rapide pour vous, en fibre sur un ordinateur récent, peut échouer parce que son public réel est en 4G sur un téléphone de trois ans.
Conséquence pratique : on diagnostique dans Lighthouse, mais on juge le résultat dans le rapport « Signaux web essentiels » de la Search Console, et avec quatre semaines de décalage. Une correction déployée aujourd’hui ne se lit pas demain.
LCP : une histoire de serveur, puis d’image
Dans la grande majorité des cas, un mauvais LCP se décompose en deux causes, dans cet ordre.
Le temps de réponse du serveur. Une page WordPress non mise en cache est reconstruite à chaque visite : PHP interroge la base, assemble, renvoie. Un cache de page bien réglé sert un fichier déjà prêt. Sur ce site, le simple fait de rendre le cache de page fonctionnel — il était neutralisé par une règle de réécriture laissée par une ancienne extension — a fait passer le temps de réponse d’environ 0,55 s à 0,1 s. Aucun plugin ajouté, une ligne retirée.
L’image de haut de page. C’est presque toujours l’élément LCP. Elle doit être dimensionnée pour son affichage réel, servie dans un format moderne, et surtout ne pas être différée : mettre en lazy-load l’image principale, c’est retarder volontairement la métrique qu’on essaie d’améliorer. Nous en avons fait l’expérience à nos dépens : un seul PNG exporté à 1,2 Mo suffit à faire dérailler le LCP d’une page par ailleurs bien construite.
INP : ce que fait votre JavaScript pendant qu’on vous clique
L’INP sanctionne le JavaScript qui monopolise le fil principal du navigateur. Le visiteur clique, le navigateur est occupé, l’interface répond en retard. Les responsables habituels sont connus : les constructeurs de pages et leur couche de scripts chargée sur chaque page, l’accumulation d’extensions qui ajoutent chacune leur bibliothèque, les carrousels, les scripts de suivi et les widgets tiers.
La bonne nouvelle : c’est la métrique où retirer du code paie le plus. La mauvaise : on ne retire pas facilement du code dont le site dépend, ce qui rejoint notre parti pris expliqué dans pourquoi nous évitons les page builders lourds. Un site construit léger n’a pas besoin d’être optimisé après coup.
CLS : le plus facile à corriger, le plus souvent négligé
Le CLS mesure les sauts de mise en page : ce moment où l’on s’apprête à cliquer et où le bouton se déplace. Les causes sont peu nombreuses et toutes réparables.
- Images et iframes sans dimensions : sans
widthetheight, le navigateur ne réserve pas la place et tout se décale à l’arrivée du fichier. - Polices web : un basculement de la police de secours vers la police finale change les hauteurs de texte. Cela se maîtrise avec le préchargement et une police de repli de métriques proches.
- Contenus injectés après coup : bandeau de cookies, alerte, publicité, bloc chargé en JavaScript — tout ce qui s’insère au-dessus du contenu déjà lu.
- Un lazy-load mal réglé, cas vécu ici : l’extension imposait une largeur de remplacement de 500 px à chaque logo d’une bande d’images. La bande occupait quatre fois sa largeur réelle, puis se repliait d’un coup. Le correctif n’était pas « plus d’optimisation », c’était d’exclure ces images du lazy-load et de déclarer leurs dimensions.
Ce que ça change vraiment pour le référencement
Soyons précis, parce que c’est là que le marketing déraille. L’expérience de la page est un signal parmi des centaines, et un signal faible : il ne fera pas remonter une page dont le contenu ne répond pas à la requête. Aucune optimisation technique ne compense un contenu qui n’a rien à dire.
Passer les seuils suffit. Courir après un score de 100 sur 100 coûte cher et ne rapporte rien.
En revanche, l’effet sur le comportement des visiteurs est direct, et il est mesurable dans vos propres statistiques : moins d’abandons au chargement, plus de pages vues, plus de formulaires terminés. C’est le vrai argument. Le référencement en bénéficie indirectement, parce que Google observe aussi ce que font les gens.
Notre ordre d’intervention
- Mesurer sur le terrain, pas seulement en laboratoire : quelles URL échouent, sur mobile ou sur ordinateur, et pour quelle métrique.
- Retirer avant d’ajouter : extensions inutiles, scripts tiers oubliés, règles mortes qui bloquent le cache.
- Régler le temps de réponse : hébergement, cache de page, version de PHP.
- Traiter les médias : dimensions réelles, formats modernes, dimensions déclarées, pas de lazy-load sur le premier écran.
- Réduire et différer le JavaScript non essentiel, en vérifiant à chaque étape que rien n’est cassé.
- Attendre. Les données de terrain se rafraîchissent sur 28 jours : juger trop vite conduit à empiler des correctifs inutiles.
Les faux amis
- Empiler les extensions d’optimisation. Deux caches qui se contredisent, c’est un site plus lent et un diagnostic impossible.
- Le score comme objectif. Un rapport vert obtenu en désactivant des fonctionnalités utiles n’est pas une amélioration, c’est un appauvrissement.
- Le « tout minifier, tout combiner » sans vérification : cela casse régulièrement des fonctionnalités, souvent sur une seule page qu’on ne teste pas.
- Optimiser une page à la fois alors que la cause est commune à tout le site : l’en-tête, les polices et les scripts globaux se corrigent une fois.
Un site à remettre dans le vert ?
Nous traitons la performance comme un sujet de construction, pas de rattrapage : c’est plus efficace et bien moins coûteux. Voir nos pages référencement naturel et maintenance WordPress, ou notre démarche de numérique responsable — la sobriété technique et la vitesse sont le même travail.
Un rapport rouge dans la Search Console et pas de piste claire ? Écrivez-nous via la page contact : nous regardons vos URL réelles et vous disons quelles causes traiter en premier — et lesquelles ne valent pas l’effort.