Core Web Vitals en 2026 : ce qui a changé et ce qui compte toujours

Les Core Web Vitals sont nés en 2020 d’une expérimentation de Google sur la performance. Six ans plus tard, ils sont intégrés à la manière dont chaque site du web ouvert est évalué. Ils constituent aussi, discrètement, l’un des signaux de classement les plus mal compris du SEO, parce que les seuils ne cessent de bouger et que la plupart des articles à leur sujet citent encore des chiffres vieux de deux ans.

Voici ce qui a changé en 2026, quels sont réellement les seuils actuels et quelles corrections font encore véritablement la différence pour le site web d’une entreprise australienne.

Les trois indicateurs, actualisés

Les Core Web Vitals sont trois indicateurs que Google utilise pour évaluer la santé technique d’une page. Chacun cible une étape différente de la façon dont un visiteur perçoit le chargement de la page.

Le LCP (Largest Contentful Paint) mesure le moment où le plus grand élément visible de la page finit de s’afficher. Les images d’en-tête, les grands titres ou les photos de produits mis en avant déclenchent souvent cet indicateur. Un bon LCP est désormais inférieur à 2,5 secondes. Au-delà de 4 secondes, c’est un échec.

L’INP (Interaction to Next Paint) a remplacé le FID (First Input Delay) en 2024 et a encore été affiné cette année. Il mesure la rapidité avec laquelle la page réagit lorsqu’un visiteur clique, tape ou saisit du texte. Un bon INP est désormais inférieur à 200 millisecondes. Au-delà de 500 millisecondes, c’est un échec.

Le CLS (Cumulative Layout Shift) mesure l’ampleur des sauts de la page pendant son chargement : publicités qui s’affichent, images sans dimensions, polices qui se substituent. Un bon CLS est inférieur à 0,1. Le seuil n’a pas changé, mais la manière dont Google le mesure au fil des sessions est devenue plus stricte.

Ce qui a discrètement changé en 2026

Google est progressivement passé de la récompense des sites qui réussissent les Core Web Vitals à la pénalisation de ceux qui échouent. En pratique, cela signifie que franchir les seuils n’apporte plus un véritable avantage, mais y échouer fait désormais reculer le classement pour les requêtes où toutes les pages concurrentes réussissent.

Le deuxième changement concerne le poids de la performance mobile. L’indexation mobile-first existe depuis des années, mais en 2026 le score des Core Web Vitals sur ordinateur est pratiquement ignoré pour le classement. Si votre site se charge correctement sur une connexion de bureau rapide mais peine sur un Android de milieu de gamme, Google voit l’expérience Android.

Les corrections qui fonctionnent vraiment

La plupart des problèmes de Core Web Vitals sur un site WordPress proviennent de la même poignée de causes. Aucune n’oblige à repartir de zéro et la plupart peuvent être réglées en une semaine de travail ciblé.

Pour le LCP : compressez agressivement les images d’en-tête et servez-les dans des formats modernes (WebP, AVIF). Ajoutez des attributs de largeur et de hauteur explicites. Intégrez le CSS critique en ligne pour que le premier affichage n’attende pas une feuille de style externe. Différez le chargement de tout ce qui se trouve sous la ligne de flottaison.

Pour l’INP : auditez vos extensions. La plupart des échecs d’INP proviennent d’une poignée d’extensions qui exécutent du JavaScript lourd à chaque interaction. Les widgets de chat en direct, les scripts d’analytics et les validateurs de formulaires sont les coupables habituels. Les différer ou les charger de façon asynchrone corrige souvent l’INP sans supprimer la fonctionnalité.

Pour le CLS : réservez de l’espace pour les emplacements publicitaires, les vidéos intégrées et le contenu chargé de façon asynchrone. Hébergez vous-même les polices critiques avec font-display réglé sur optional. Évitez d’injecter du contenu au-dessus du contenu existant après le chargement de la page.

Ce qu’il faut ignorer

Les scores de performance de Lighthouse ne sont pas les Core Web Vitals. Ils en sont une simulation imparfaite. Une page peut obtenir 100 sous Lighthouse et échouer malgré tout aux Core Web Vitals réels, car les visiteurs utilisent des appareils plus lents que le laboratoire. Les chiffres qui comptent se trouvent dans la Google Search Console, sous « Expérience sur la page », parce qu’ils proviennent d’utilisateurs réels.

Ignorez les extensions qui promettent de « corriger les Core Web Vitals » d’un simple bouton. La plupart suppriment les symptômes en différant tout de façon indiscriminée, ce qui casse des éléments visuels, bloque du JavaScript légitime et échange un problème contre un autre. Le vrai travail de performance est chirurgical, pas chimique.

Combien de travail de performance en vaut la peine

Si votre Search Console indique que votre site échoue aux Core Web Vitals sur plus d’un tiers de ses pages, le travail de performance a un argument de ROI solide. Les sites qui passent de l’échec à la réussite constatent régulièrement une progression à la fois du classement et du taux de conversion en moins de trois mois.

Si votre site réussit déjà, concentrez votre énergie sur le contenu, les liens et la conversion. La performance n’est pas l’endroit où courir après les derniers 5 %, sauf si vous visez un mot-clé commercial à fort enjeu où chaque point de pourcentage compte.

Pour un site WordPress qui doit passer de l’échec à la réussite, une passe de performance ciblée par l’équipe de Defyn identifie généralement les cinq corrections prioritaires en une journée et les déploie en une semaine. Les chiffres se mettent à jour dans la Search Console deux à quatre semaines après la mise en ligne des corrections, et la progression du classement, lorsqu’elle survient, concerne surtout les requêtes qui comptent le plus.

Les Core Web Vitals ne sont pas le seul signal de classement qui compte, mais en 2026 ils sont l’un des rares signaux capables de faire chuter un site sans que cela soit évident. Ils méritent d’être compris, mesurés et corrigés correctement une bonne fois.