Core Web Vitals en 2026 : ce qui fait vraiment bouger le classement

Ce que mesurent aujourd’hui les Core Web Vitals

Les Core Web Vitals sont trois métriques qui décrivent le ressenti d’une page pour de vrais visiteurs. Le Largest Contentful Paint (LCP) mesure le chargement : le temps avant que l’image ou le bloc de texte principal soit visible. L’Interaction to Next Paint (INP) mesure la réactivité : le temps que met la page à réagir visiblement après un appui, un clic ou une touche. Le Cumulative Layout Shift (CLS) mesure la stabilité visuelle : à quel point le contenu bouge pendant le chargement.

Une page est validée quand au moins 75 % des visites sont dans la zone « bonne » : LCP inférieur ou égal à 2,5 secondes, INP inférieur ou égal à 200 millisecondes et CLS inférieur ou égal à 0,1. Mobile et ordinateur sont évalués séparément, et le mobile est presque toujours le plus difficile.

L’INP a remplacé le First Input Delay (FID) comme Core Web Vital en mars 2024. Le FID ne mesurait que le délai de la première interaction ; l’INP prend en compte les interactions les plus lentes de toute la visite. Beaucoup de sites confortablement au vert avec le FID sont passés à l’orange ou au rouge avec l’INP.

Quel poids dans le classement ?

Les Core Web Vitals font partie des signaux d’expérience de page de Google. Elles ne passent pas avant la pertinence : une page lente avec la meilleure réponse battra toujours une page rapide avec une réponse faible. Elles comptent entre pages de qualité similaire, et surtout pour la conversion : les visiteurs quittent les pages lentes et instables, quel que soit leur classement.

C’est pourquoi nous traitons ces métriques d’abord comme un indicateur business, ensuite comme un indicateur SEO. Des pages rapides vendent plus, génèrent plus de demandes et coûtent moins cher en trafic payant.

Données terrain et données de laboratoire

Lighthouse et les scores de laboratoire de PageSpeed Insights simulent une seule visite sur un appareil bridé. Ils sont utiles pour déboguer, mais Google classe selon les données terrain du Chrome User Experience Report (CrUX), collectées auprès de vrais utilisateurs de Chrome sur 28 jours.

Commencez par le rapport Core Web Vitals de Search Console pour voir quels groupes d’URL échouent et sur quelle métrique. Utilisez ensuite PageSpeed Insights pour les données terrain d’une URL précise, et le panneau Performance de Chrome DevTools pour trouver la cause.

Améliorer le LCP

La plupart des problèmes de LCP viennent de quatre sources : une réponse serveur lente, une image principale découverte tardivement, du CSS et des polices qui bloquent le rendu, ou une image tout simplement trop lourde.

• Ramenez le Time to First Byte sous environ 800 ms : cache de pages complètes pour les visiteurs anonymes, CDN et requêtes de base de données rapides.
• Ne chargez jamais l’image du LCP en lazy-load. Donnez-lui fetchpriority="high" et préchargez-la si elle est définie en CSS.
• Servez de l’AVIF ou du WebP à la bonne taille avec srcset et sizes, plutôt qu’un gros JPEG.
• Intégrez le CSS critique et chargez le reste sans bloquer ; hébergez vos polices et utilisez font-display: swap.

Améliorer l’INP

L’INP est presque toujours un problème de JavaScript. Quand le thread principal est occupé par une tâche longue — tout ce qui dépasse 50 ms —, le navigateur ne peut pas répondre à l’appui de l’utilisateur avant la fin.

Auditez d’abord les scripts tiers : chats, cartes de chaleur, outils d’A/B test et plusieurs conteneurs de balises ajoutent souvent des centaines de millisecondes. Chargez-les après une interaction ou seulement sur certaines pages. Dans votre propre code, gardez des gestionnaires d’événements légers, appliquez un debounce aux saisies et découpez les traitements longs pour laisser le navigateur afficher entre deux. Un DOM très volumineux (plusieurs milliers d’éléments) ralentit aussi chaque interaction, ce qui est courant avec les constructeurs de pages.

// Let the browser paint between chunks of heavy work
async function processInChunks(items, handle) {
  for (const item of items) {
    handle(item);
    await new Promise((resolve) => setTimeout(resolve, 0));
  }
}

Améliorer le CLS

• Définissez toujours width et height (ou aspect-ratio) pour les images, vidéos et iframes.
• Réservez l’espace des publicités, contenus intégrés et bandeaux cookies au lieu de pousser le contenu à leur chargement.
• Évitez d’insérer des bandeaux ou messages au-dessus du contenu une fois la page affichée.
• Utilisez des polices de secours aux métriques équivalentes (size-adjust) pour que le texte ne se réorganise pas à l’arrivée de la police web.

Spécificités Laravel et WordPress

Sous Laravel, les gains rapides sont les caches de production (php artisan config:cache, route:cache, view:cache), OPcache, Redis pour le cache et les sessions, et l’eager loading pour supprimer les requêtes N+1 qui ralentissent le premier octet. Compilez les ressources avec Vite pour minifier et versionner CSS et JavaScript, et déplacez les traitements lents comme les e-mails et appels d’API vers des files d’attente.

Sous WordPress, la plupart des problèmes viennent des extensions. Supprimez celles qui ne servent pas, utilisez un vrai cache de pages (LiteSpeed Cache fonctionne très bien sur les serveurs LiteSpeed), optimisez les images à l’envoi, gardez PHP sur une version 8.x maintenue et méfiez-vous des constructeurs de pages lourds.

Mesurer, puis patienter

Ajoutez la bibliothèque open source web-vitals pour envoyer les vraies valeurs de LCP, INP et CLS à GA4 ou à votre propre point de collecte : vous verrez l’effet en quelques jours sans attendre CrUX. Le rapport de Search Console utilise une fenêtre glissante de 28 jours ; après une correction, il faut donc environ quatre semaines pour passer au vert. Validez la correction à cet endroit une fois les nouvelles données arrivées.

Pour un premier aperçu rapide de votre site, notre analyse de site gratuite signale les réponses lentes, l’absence de compression et d’autres causes fréquentes.