Core Web Vitals en 2026 : comment réussir LCP, INP et CLS

Les Core Web Vitals sont la manière dont Google mesure si une page paraît rapide, réactive et stable pour de vraies personnes. Ils comptent à double titre : comme signaux d’expérience de page, et parce qu’une page lente ou instable fait fuir les visiteurs avant qu’ils lisent votre offre. Ce guide présente les trois indicateurs et les corrections qui apportent généralement les plus grands gains.

Les trois indicateurs et leurs objectifs

Google évalue chaque indicateur au 75e centile des visites réelles, séparément sur mobile et ordinateur. Pour être jugée « bonne », une page doit atteindre :

• Largest Contentful Paint (LCP) : 2,5 secondes ou moins. La rapidité d’affichage du contenu principal, souvent une image de tête ou un titre.
• Interaction to Next Paint (INP) : 200 millisecondes ou moins. La rapidité avec laquelle la page réagit visuellement aux clics, appuis et frappes pendant toute la visite. L’INP a remplacé le First Input Delay en mars 2024.
• Cumulative Layout Shift (CLS) : 0,1 ou moins. L’ampleur des déplacements du contenu visible pendant le chargement.

Bien mesurer

Utilisez deux types de données, car elles répondent à des questions différentes :

1. Les données terrain issues de vrais visiteurs : le rapport Core Web Vitals de la Search Console et le Chrome UX Report, aussi visibles dans PageSpeed Insights. C’est ce que Google utilise.
2. Les données de laboratoire issues d’un test contrôlé : Lighthouse et l’onglet Performance de Chrome DevTools. Elles servent à trouver et corriger les causes, car elles sont reproductibles.

Un bon score en laboratoire ne garantit pas un bon score terrain, vérifiez donc toujours les deux.

Corriger le LCP

Le LCP est généralement une image ou un grand bloc de texte. Traitez les délais dans l’ordre :

• Identifiez l’élément LCP dans DevTools, puis assurez-vous qu’il est présent dans le HTML et découvrable tôt, et non injecté tardivement par JavaScript.
• Ne chargez jamais en différé l’image LCP. Chargez-la immédiatement et envisagez une indication de priorité élevée.
• Servez des images adaptées et modernes en AVIF ou WebP avec des tailles `srcset` responsives.
• Réduisez le temps de réponse du serveur avec du cache, un réseau de diffusion de contenu et un hébergement efficace.
• Supprimez les ressources bloquant le rendu : CSS critique en ligne, scripts non essentiels différés, polices clés préchargées.
• Pré-rendez ou générez statiquement vos pages pour que le navigateur reçoive immédiatement du vrai contenu plutôt qu’une coquille vide.

Corriger l’INP

Un mauvais INP vient presque toujours d’un thread principal occupé au moment de l’interaction.

• Découpez les tâches longues pour que le navigateur puisse répondre entre deux blocs de travail.
• Envoyez moins de JavaScript : découpage par route, dépendances inutiles supprimées, fonctionnalités lourdes chargées à la demande.
• Auditez les scripts tiers comme les widgets de chat, gestionnaires de balises et traceurs, souvent en cause. Retardez ou supprimez ceux qui ne justifient pas leur coût.
• Gardez les gestionnaires d’événements légers et évitez de forcer de gros recalculs de mise en page à chaque interaction.
• Donnez un retour visuel immédiat comme un état pressé ou un indicateur de chargement, puis effectuez le travail lourd.

Corriger le CLS

Les décalages de mise en page viennent de contenus qui apparaissent sans espace réservé.

• Définissez largeur et hauteur (ou un ratio) sur chaque image, vidéo et contenu intégré.
• Réservez l’espace des publicités, bannières, avis de cookies et widgets tardifs.
• Chargez les polices avec soin via `font-display` et des polices de secours ajustées en taille, pour éviter que le texte saute à l’arrivée de la police web.
• N’insérez jamais de contenu au-dessus d’un contenu existant après le chargement, sauf en réponse à une action de l’utilisateur.

Un ordre de travail simple

1. Testez vos modèles de pages clés dans PageSpeed Insights et notez l’indicateur en échec.
2. Corrigez d’abord la cause principale, souvent l’image de tête, un script lourd ou des dimensions manquantes.
3. Testez à nouveau, déployez et attendez la mise à jour des données terrain, ce qui peut prendre plusieurs semaines.
4. Ajoutez des budgets de performance à votre build pour détecter les régressions avant la mise en production.

Pourquoi cela rapporte

Des pages plus rapides et plus stables convertissent en général mieux, réduisent les abandons et renforcent la confiance. Notre offre Growth inclut la validation des Core Web Vitals en standard. Si votre site échoue, notre équipe de développement web peut l’auditer et corriger les causes, ou contactez-nous pour un diagnostic rapide.