Core Web Vitals WordPress : LCP, INP, CLS et ce qui les casse chez vous

Les seuils, en chiffres

C'est la première chose que les gens cherchent, et c'est aussi ce que certains guides du top 10 oublient de donner. Les voici, tels que Google les publie sur web.dev.

Deux précisions que le tableau seul ne dit pas, et elles changent la lecture.

75^e centile. Votre LCP n'est pas la moyenne de vos visiteurs, c'est la valeur en dessous de laquelle 75 % d'entre eux se situent. Autrement dit : votre quart le plus malchanceux — vieux téléphone, 4G en zone blanche — décide de votre note. C'est un choix délibéré de Google, et c'est pour ça qu'un site qui vole sur votre MacBook peut être classé « mauvais ».

Trois sur trois. Une URL n'est « bonne » dans le rapport Signaux web essentiels que si les trois métriques passent. Un LCP à 1,8 s et un CLS à 0,02 ne rachètent pas un INP à 640 ms. Il n'y a pas de moyenne, pas de compensation.

INP a remplacé FID : ce que ça change vraiment

Le 12 mars 2024, Google a retiré FID des Core Web Vitals et l'a remplacé par INP. Beaucoup d'articles — et pas mal d'outils — n'ont pas suivi. Si vous lisez encore « FID < 100 ms » quelque part, la page date.

Ce n'est pas un renommage. FID ne mesurait que le délai avant la prise en compte de votre première interaction. Un site pouvait afficher un FID excellent et rester atroce à l'usage : le premier clic était enregistré vite, puis rien ne se passait à l'écran pendant une seconde. FID s'arrêtait de compter avant le moment qui vous intéresse.

INP mesure autre chose : le délai entre l'interaction et la mise à jour visible de la page, et il le fait sur toutes les interactions de la visite, pas seulement la première. Le score retenu est à peu près la pire d'entre elles. Concrètement, si l'ouverture de votre menu burger met 700 ms à répondre au dixième clic de la session, INP le voit. FID ne le voyait jamais.

Pour un site WordPress, ce basculement est brutal, parce que les interactions arrivent tard : menu déroulant, filtres de boutique, ouverture du panier, accordéon de FAQ, lecteur de galerie. Tout ce qui est piloté par le JavaScript d'un constructeur de page ou d'un plugin tiers.

Labo ou terrain : deux chiffres, deux histoires

C'est la confusion n°1, et elle produit des heures perdues. Quand vous lancez PageSpeed Insights, vous obtenez deux blocs de données qui n'ont rien à voir.

• Les données de labo (Lighthouse). Un navigateur sans utilisateur charge votre page une fois, depuis un serveur de Google, sur un profil mobile bridé. Reproductible, disponible immédiatement, y compris sur un site sans visiteurs. Mais c'est une simulation : personne ne clique, donc INP est impossible à mesurer en labo.
• Les données terrain (CrUX). Ce que vivent vos vrais visiteurs sous Chrome, agrégé sur 28 jours glissants. C'est ce que Google utilise pour le classement, c'est ce qu'affiche la Search Console. Mais il faut assez de trafic pour que l'échantillon existe : en dessous, Google ne rend rien du tout.

D'où trois conséquences pratiques.

Un score Lighthouse de 100 ne garantit rien. Le score de labo est une note de causes probables. Vos visiteurs peuvent quand même être en « mauvais » sur le terrain — cache froid, région lointaine, réseau réel, extensions de navigateur.

Un correctif ne se voit pas tout de suite. CrUX est une fenêtre glissante de 28 jours : le jour où vous déployez, votre chiffre contient encore 28 jours de l'ancienne version. Comptez un mois complet avant que la Search Console reflète pleinement le correctif — et ne relancez pas la validation tous les trois jours, ça ne l'accélère pas. Si votre rapport affiche justement « L'évaluation Core Web Vitals a échoué », cette page dédiée détaille quelle métrique fait basculer une URL et pourquoi le statut traîne.

Sans trafic, pas de terrain. Si votre site fait 30 visites par mois, CrUX n'aura jamais d'échantillon pour vous. Ce n'est pas une panne, et ce n'est pas grave : dans ce cas les données de labo sont tout ce que vous avez, et elles suffisent pour corriger les causes.

Ce que notre rapport affiche, et combien ça coûte de points

Plutôt que de vous expliquer comment aller chercher ces chiffres vous-même, voici ce que le moteur en fait quand vous collez votre URL. Le barème est celui du code, pas une brochure : chaque ligne correspond à un check de analyzePerformance().

Vous avez remarqué qu'cwv_inp ne coûte aucun point. C'est un choix, et je l'assume : INP n'existe que si CrUX a un échantillon de vos visiteurs. Facturer des points sur cette ligne reviendrait à pénaliser les petits sites pour le silence de Google, pas pour leur code. Vous voyez la valeur, elle est classée avec les vrais seuils, elle ne touche pas au score. Quand Google n'a pas d'échantillon, le rapport l'écrit noir sur blanc — « No CrUX sample » — au lieu d'afficher un zéro rassurant.

Et c'est cwv_tbt qui paie à sa place. Le Total Blocking Time mesure combien de temps le thread principal est bloqué par de longues tâches JavaScript pendant le chargement : c'est la cause la plus courante d'un mauvais INP, et elle, on sait la mesurer sur n'importe quel site, avec ou sans trafic.

Les causes WordPress, métrique par métrique

Ce qui suit n'est pas une liste de bonnes pratiques : ce sont les configurations qui reviennent dans les rapports, avec l'endroit exact où regarder.

LCP : presque toujours l'image du haut

Sur un site WordPress vitrine, l'élément LCP est neuf fois sur dix l'image d'en-tête. Et le drame habituel est une optimisation qui se retourne contre vous : le plugin de cache active le lazy-load « sur toutes les images », donc y compris celle du hero. Le navigateur attend d'avoir exécuté le JavaScript pour découvrir qu'il doit télécharger l'image la plus importante de la page. Une seconde perdue, gratuitement, par une case cochée pour aller plus vite.

Le réflexe : exclure l'image hero du lazy-load (tous les plugins sérieux ont ce champ d'exclusion), et vérifier qu'elle porte bien fetchpriority="high" — WordPress le pose automatiquement depuis la 6.3 sur l'image qu'il pense être le LCP, mais un thème ou un constructeur de page qui génère son propre balisage passe souvent à côté.

Le second suspect est la police web. Un @font-face sans font-display: swap rend le texte invisible pendant le téléchargement : si votre LCP est un titre, il attend la police. Le moteur vérifie ce point (font_loading) et vous le remonte.

INP : le JavaScript que vous n'avez pas écrit

Le coupable est rarement le cœur de WordPress : c'est l'empilement. Un constructeur de page qui charge son bundle sur toutes les pages, un widget de chat chargé en synchrone, trois tags analytics, un plugin de partage social, un slider. Chacun ajoute des tâches longues sur le thread principal. Tant que le thread est occupé, votre clic attend.

C'est là que le scan sert à autre chose qu'à un score : le rapport liste les domaines tiers détectés dans votre HTML et le nombre de scripts par domaine (check third_party). Vous voyez nommément qui s'est invité sur votre page. Un site correct tient sous trois domaines tiers ; au-delà de neuf, la sanction tombe et elle est méritée.

Le tri est ingrat mais simple : désactiver un plugin, rescanner, comparer. Rien ne remplace ça, et surtout pas un avis générique sur « les plugins qui ralentissent WordPress ».

CLS : ce qui arrive après coup

Le CLS n'est pas un problème de vitesse, c'est un problème de place réservée. Les trois classiques :

1. Images sans width ni height. Le navigateur ne sait pas quelle hauteur réserver, il pose le texte, puis l'image arrive et pousse tout vers le bas. WordPress ajoute ces attributs tout seul depuis la 5.5 — sauf quand le HTML est produit par un thème ou un shortcode qui les omet.
2. Le bandeau cookies injecté en JavaScript. Il s'affiche 300 ms après le reste et décale toute la page. Réservez sa hauteur, ou affichez-le en overlay au lieu de le pousser dans le flux.
3. Les polices. font-display: swap corrige le texte invisible mais crée un ressaut si la police de secours n'a pas les mêmes métriques. size-adjust ou font-family de secours bien choisie règlent la question.

Ce que ce scan ne vous dira pas

Autant l'écrire avant que vous ne payiez quoi que ce soit.

• Quel élément précis est votre LCP. Lighthouse le sait, notre rapport ne le sort pas encore. Aujourd'hui, pour avoir le sélecteur exact, il faut ouvrir PageSpeed Insights et dérouler « Diagnostics ». C'est sur ma liste, ce n'est pas encore dans le produit.
• Votre INP si vous n'avez pas de trafic. Voir plus haut : pas d'échantillon CrUX, pas de chiffre. Le rapport le dit plutôt que d'inventer.
• Le reste de votre site. Une URL par scan. Votre page d'accueil peut être verte pendant que vos fiches produit sont rouges — et Google évalue par groupe d'URL, pas par page d'accueil.
• Ce qui se passe dans votre base. Un wp_options gonflé d'options en autoload par des plugins désinstallés en 2021 dégrade le TTFB, donc le LCP, sans aucune trace visible de l'extérieur.

Une dernière chose, sur la neutralité. Je ne vends ni plugin de cache, ni hébergement, ni prestation d'optimisation. C'est la raison pour laquelle cette page ne se termine pas par « et donc installez notre extension » : je vends le diagnostic, pas le remède, ce qui m'évite de vous prescrire ce que je vends.

Ponctuel ou continu ?

Continu, et pas parce qu'on vend un abonnement. Un guide se lit une fois ; une régression CWV, elle, revient. La séquence est toujours la même : vous corrigez, vous passez au vert, et trois mois plus tard une mise à jour de plugin recharge un bundle JavaScript sur toutes les pages. Personne ne le voit — le site fonctionne — jusqu'au jour où la Search Console repasse le groupe d'URL en rouge, avec un mois de retard à cause de la fenêtre glissante.

D'où le monitoring de la formule Pro : le même scan, automatique, à intervalle régulier, avec l'historique. Il ne rend pas votre site plus rapide, il vous dit quel jour il a ralenti. Franchement : si vous gérez un seul site que vous ne touchez jamais, un scan gratuit après chaque intervention suffit largement. Le Pro n'a de sens qu'à partir de plusieurs sites ou d'un site qui bouge toutes les semaines.

Questions fréquentes