« L'évaluation Core Web Vitals a échoué » : ce que la Search Console vous dit vraiment
Le rapport Signaux web essentiels affiche « Échec » sur un groupe d'URL et ne vous dit pas laquelle des trois métriques a fauté. Pire : le statut reste rouge des semaines après que vous ayez corrigé. Cette page explique ce que ce mot veut dire exactement, quelle métrique fait basculer en échec, pourquoi le statut traîne, et comment isoler la cause sans attendre.
En résumé : « Échec de l'évaluation » signifie qu'au moins une de vos trois métriques — LCP, INP ou CLS — dépasse le seuil « Mauvais » au 75e centile de vos vrais visiteurs, sur mobile ou desktop. Sur WordPress, le coupable le plus fréquent est l'INP, à cause du JavaScript des constructeurs de page. Le statut reste en échec jusqu'à 28 jours après votre correction parce que les données terrain sont agrégées sur une fenêtre glissante : relancer la validation ne l'accélère pas. Pour savoir quelle métrique faute sans attendre, on lit le TBT en labo, qui est le substitut mesurable de l'INP.
« Échec » vs « À améliorer » vs « Correct »
La Search Console range chaque groupe d'URL dans l'un de trois états, et le vocabulaire prête à confusion parce qu'il ne colle pas aux trois seuils d'une métrique isolée.
| Statut affiché | Condition |
|---|---|
| Correct (« Bon ») | Les trois métriques sont dans le vert au 75e centile. C'est le seul état qui compte comme « URL valides ». |
| À améliorer | Aucune métrique n'est « Mauvais », mais au moins une est dans la zone orange (« À améliorer »). |
| Médiocre / Échec | Au moins une métrique est dans le rouge (« Mauvais »). C'est le déclencheur du message « L'évaluation a échoué ». |
Deux pièges de lecture ici. D'abord, l'évaluation est jugée sur la pire des trois métriques : un LCP magnifique à 1,2 s et un CLS à 0,01 ne rachètent pas un INP à 620 ms. Il n'y a pas de moyenne. Ensuite, l'évaluation est faite séparément sur mobile et sur desktop. Vous pouvez être « Correct » sur desktop et en « Échec » sur mobile — et c'est le mobile qui pèse dans le classement, parce que Google indexe mobile-first.
Autre subtilité : un groupe d'URL peut passer d'« Échec » à « URL valides » sans que vous n'ayez rien touché, simplement parce que Google a réévalué avec de nouvelles données terrain. L'inverse est vrai aussi. Le statut suit vos vrais visiteurs, pas une note figée.
Les 3 causes qui font basculer une URL en échec
Une seule suffit. Voici les trois, avec le seuil rouge exact au 75e centile.
| Métrique | Seuil « Mauvais » | Fréquence sur WordPress |
|---|---|---|
| INP — réactivité | > 500 ms | La plus fréquente. Le JavaScript des constructeurs de page (Elementor, Divi) et des widgets tiers bloque le thread principal. |
| LCP — vitesse d'affichage | > 4,0 s | Fréquente. Image hero mise en lazy-load par le plugin de cache, hébergement mutualisé lent, polices bloquantes. |
| CLS — stabilité visuelle | > 0,25 | Moins fréquente depuis que WordPress pose width/height tout seul. Reste le bandeau cookies injecté après coup. |
Sur WordPress, c'est l'INP qui fait échouer le plus souvent. Et c'est logique : depuis que Google a remplacé FID par INP le 12 mars 2024, la métrique de réactivité regarde toutes les interactions de la visite, pas seulement la première, et retient la pire. Un menu déroulant qui met 600 ms à s'ouvrir au dixième clic de la session, INP le voit. FID ne le voyait jamais. Un site qui était « Correct » sous FID a pu basculer en « Échec » ce jour-là sans qu'une seule ligne de code ne change chez vous.
Pourquoi le statut reste en échec après votre correction
C'est la question qui rend les gens fous, et la réponse tient en deux mots : fenêtre glissante. Le rapport Signaux web essentiels ne lit pas votre code ; il lit les données du Chrome UX Report, agrégées sur 28 jours glissants. Le lendemain du jour où vous corrigez, votre chiffre contient encore 27 jours de l'ancienne version, lente. Le statut ne peut pas bouger tant que la mauvaise donnée n'est pas sortie de la fenêtre.
Concrètement :
- Jour 0. Vous déployez le correctif. Aucun effet visible dans la Search Console.
- Jour 1 à 27. La fenêtre se remplit progressivement de bonnes données, mais la moyenne reste tirée vers le bas par l'ancien. Le 75e centile bouge lentement.
- Vers le jour 28. La dernière journée « lente » sort de la fenêtre. Le statut reflète enfin votre correction — à condition qu'il y ait assez de trafic pour maintenir l'échantillon.
Le bouton « Valider la correction » ne raccourcit pas ce délai. Il déclenche une revérification par Google, mais Google revérifie sur… les mêmes données terrain à 28 jours. Cliquer trois fois par semaine ne fait qu'ajouter des tentatives « échouées » à votre historique. Cliquez une fois, une fois que vous êtes sûr du correctif, et attendez. La validation peut durer plusieurs jours côté Google : c'est normal.
Un cas particulier : si votre URL a peu de trafic, l'échantillon CrUX peut disparaître complètement. Le groupe bascule alors en « URL sans données suffisantes », pas en « Correct ». Ce n'est pas un échec, c'est l'absence de mesure. Pour ces pages, seul le labo (Lighthouse / TBT) vous renseigne.
Isoler la métrique fautive sans attendre 28 jours
La Search Console vous dit qu'une URL a échoué, mais elle est avare sur le « laquelle ». Et son chiffre est en retard de 28 jours. Pour savoir tout de suite ce qui cloche, il faut mesurer en labo — ce que fait le scan quand vous collez votre URL.
Analysez l'URL en échec
Collez l'adresse exacte que la Search Console signale. Le moteur récupère vos données de labo Lighthouse et vos données terrain CrUX quand elles existent, et vous rend LCP, CLS, TBT — le tout en une trentaine de secondes, sans inscription.
Le moteur lit votre page depuis l'extérieur, comme le fait Google pour construire ses données de labo.
La subtilité utile est là : l'INP ne se mesure pas en labo. En labo, personne ne clique, donc aucune interaction à chronométrer. Si votre échec vient de l'INP et que vous n'avez pas de trafic CrUX, aucun outil au monde ne vous sortira le chiffre. Mais il existe un substitut mesurable : le TBT (Total Blocking Time). Le TBT mesure combien de temps le thread principal est bloqué par de longues tâches JavaScript pendant le chargement — c'est-à-dire la cause la plus courante d'un mauvais INP. Un TBT élevé en labo est votre meilleur indice que l'INP est le coupable en terrain.
La lecture pratique du rapport :
- LCP > 4 s en labo → votre échec vient probablement du LCP. Regardez l'image du haut et le TTFB.
- CLS > 0,25 en labo → votre échec vient du CLS. Cherchez les images sans dimensions et le contenu injecté après coup.
- LCP et CLS dans le vert, mais TBT élevé → l'échec vient très probablement de l'INP. Le labo ne le chiffre pas, mais le TBT le trahit. Traquez le JavaScript tiers.
Le rapport liste aussi les domaines tiers détectés sur votre page et le nombre de scripts par domaine. Quand l'INP est en cause, c'est là que vous trouvez qui bloque le thread : chat, tags analytics, constructeur de page, widget de partage.
Correctifs WordPress, métrique par métrique
Si l'échec vient du LCP
Le réflexe n°1 : exclure l'image hero du lazy-load. Le plugin de cache active souvent le lazy-load « sur toutes les images », y compris celle du haut, ce qui retarde l'élément le plus important de la page. Tous les plugins sérieux (WP Rocket, LiteSpeed Cache) ont un champ d'exclusion. Vérifiez aussi que l'image porte fetchpriority="high" — WordPress le pose depuis la 6.3, mais un thème qui génère son propre balisage passe souvent à côté. Ensuite : images en WebP, un vrai cache de page, et si le TTFB reste haut, un hébergement moins saturé qu'un mutualisé à 3 €/mois.
Si l'échec vient de l'INP (ou d'un TBT élevé)
Le coupable est rarement le cœur de WordPress : c'est l'empilement de JavaScript tiers. Un constructeur de page qui charge son bundle partout, un widget de chat en synchrone, trois tags analytics, un slider. La méthode est ingrate mais imparable : désactiver un plugin, rescanner, comparer le TBT. Différez ou retardez les scripts non critiques (la plupart des plugins de cache proposent « delay JavaScript execution »). Un site correct tient sous trois domaines tiers ; au-delà de neuf, l'INP souffre et c'est mérité.
Si l'échec vient du CLS
Trois classiques. Les images sans width ni height — WordPress les ajoute depuis la 5.5, sauf quand le HTML sort d'un shortcode ou d'un thème qui les omet. Le bandeau cookies injecté en JavaScript, qui s'affiche 300 ms après le reste et pousse toute la page : réservez sa hauteur ou affichez-le en overlay. Les polices web : 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 une police de repli bien choisie règlent ça.
Questions fréquentes
Pourquoi mon URL reste-t-elle en « Échec » alors que j'ai corrigé ?
Parce que la Search Console lit les données terrain du Chrome UX Report, agrégées sur une fenêtre glissante de 28 jours. Le lendemain de votre correction, la fenêtre contient encore 27 jours de l'ancienne version lente. Le statut ne peut refléter pleinement le correctif qu'une fois cette période écoulée. Relancer la validation n'accélère rien.
Quelle métrique fait échouer le plus souvent un WordPress ?
L'INP, dans la plupart des cas. Depuis qu'il a remplacé FID en mars 2024, il mesure la réactivité sur toutes les interactions de la visite et retient la pire. Le JavaScript des constructeurs de page et des widgets tiers bloque le thread principal, ce qui fait grimper l'INP au-dessus du seuil de 500 ms. Le LCP vient ensuite, souvent à cause de l'image hero en lazy-load.
Comment savoir quelle métrique faute si je n'ai pas de trafic ?
En lisant le TBT (Total Blocking Time) en labo. L'INP ne se mesure que sur de vrais clics, donc sans trafic CrUX il n'y a pas de chiffre. Mais le TBT mesure combien de temps le thread principal est bloqué par le JavaScript pendant le chargement, ce qui est la cause principale d'un mauvais INP. Un TBT élevé avec un LCP et un CLS corrects pointe vers l'INP.
Faut-il cliquer sur « Valider la correction » ?
Une seule fois, quand vous êtes sûr que le correctif est déployé. Le bouton déclenche une revérification, mais Google revérifie sur les mêmes données terrain à 28 jours : cliquer plusieurs fois n'accélère pas et ajoute des tentatives « échouées » à l'historique. Après le clic, la validation peut prendre plusieurs jours côté Google, c'est normal.
« Échec » et « URL sans données suffisantes », est-ce pareil ?
Non. « Échec » signifie qu'au moins une métrique dépasse le seuil « Mauvais » sur de vraies données. « URL sans données suffisantes » signifie que Google n'a pas assez de trafic Chrome pour constituer un échantillon : il n'y a pas de mesure du tout, ce qui n'est pas une pénalité. Pour ces pages, seul le labo vous renseigne.
Un seul mauvais chiffre suffit-il à faire échouer l'évaluation ?
Oui. L'évaluation est jugée sur la pire des trois métriques : un LCP et un CLS excellents ne compensent pas un INP au rouge. Et l'évaluation se fait séparément sur mobile et desktop, donc un échec sur mobile suffit à faire basculer le groupe d'URL, même si le desktop est correct.
Trouver la métrique qui fait échouer votre page
LCP, CLS, TBT et les scripts tiers détectés sur l'URL exacte que la Search Console signale. 30 secondes, aucune inscription.
Analyser mon URL en échec3 analyses gratuites par mois · rapport complet à 9,90 € TTC, paiement unique Stripe · export PDF inclus